587499 - firefox should use ARGB instead of XRGB for rendering pixmaps in canvas

Status: RESOLVED WONTFIX

(Core :: Graphics: Canvas2D, enhancement)

Description

[Xavier Chantry]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100724 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100724 Firefox/3.6.8

Mozilla should use ARGB instead of XRGB, because that will be hardware accelerated (XRender and opengl disagree on what should be sampled when going outside the texture without an alpha channel).
source : http://lists.freedesktop.org/archives/nouveau/2010-August/006214.html



Reproducible: Always

Steps to Reproduce:
url to reproduce :
- https://developer.mozilla.org/samples/canvas-tutorial/3_2_canvas_drawimage.html
- http://www.google.com/images?hl=en&source=imghp&q=firefox&biw=1408&bih=674
Actual Results:  
A software fallback happens and rendering is done with pixman rather than being hardware accelerated.
This at least happens with all nvidia cards I have using the nouveau driver, but it might happen with radeon too.

For reference, the code of the triggered sw fallback can be seen there :
http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nv50_exa.c#n558

Expected Results:  
If possible, firefox should try to use picture formats that can be hw accelerated.

17:57 < shining> can you elaborate on the ARGB/XRGB issue so that a real dummy (me :)) could understand ?
17:58 < stillunknown> XRGB = no alpha channel
17:58 < stillunknown> ARGB = alpha channel
17:58 < stillunknown> xrender says that any pixel sampled outside pixmap has to be transparent
17:59 < stillunknown> opengl says that the texture doesn't have an alpha channel, so it samples black
18:00 < stillunknown> only intel has some special non conforming mode that allows it to have a transparent border
18:00 < stillunknown> we assume that untransformed pixmaps are clipped, so those are hardware accelerated
18:01 < stillunknown> this only happens for unrepeated pixmaps ofcourse



I believe the code in content/canvas/src/nsCanvasRenderingContext2D.cpp might be relevant, though I am not sure.

Comment 1

[Siarhei Siamashka]

Or alternatively PAD repeat can be set on the source images at least in some cases. Everything depends on whether it is preferable (for performance reasons) to have SRC compositing operation instead of OVER for some images which are known to be opaque. Also see bug 568767 for more details.

Comment 2

[Xavier Chantry]

(In reply to comment #1)
> Or alternatively PAD repeat can be set on the source images at least in some
> cases. Everything depends on whether it is preferable (for performance reasons)
> to have SRC compositing operation instead of OVER for some images which are
> known to be opaque. Also see bug 568767 for more details.

http://lists.freedesktop.org/archives/nouveau/2010-October/006665.html
"nv40+ will be fine, older cards can't repeat NPOT textures. So in that
sense switching to ARGB is better than RepeatPad."

Comment 3

[Siarhei Siamashka]

Maybe that's true for NVIDIA hardware. But for non-hardware accelerated graphics (software rendering), using ARGB with OVER compositing operator instead of SRC is slower and consumes more energy (which is important for battery powered devices). So looks like either way somebody is going to be unhappy.

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

"for rendering pixmaps in canvas" means "for drawing images into a canvas"?  If so, the source image is outside of canvas's control -- it takes whatever is given to it by layout/imglib.  If that needs to do better detection of when an image does/does not have alpha, then we should fix that..

Comment 5

[Siarhei Siamashka]

Based on the information from the first link in the initial report, the problem seems to be related to the use of scaled XRGB image with NONE repeat and BILINEAR filter. This type of operation is problematic for both NVIDIA and ATI/AMD video cards because sampling of the pixels outside the source image may happen when using BILINEAR filter. And NONE repeat is hard or impossible to be handled for XRGB format exactly as dictated by RENDER spec for those outside-of-source-image pixels by a lot of graphics accelerators.

If I understand it correctly, Xavier suggests to use ARGB format for all the images without exception. By setting alpha channel to 0xFF for all pixels in the images which originally used to be in XRGB format.

Comment 6

[Bas Schouten (:bas.schouten)]

Benoit, you know a lot more about Pixmaps than me, what do you think?

Comment 7

[Karl Tomlinson (:karlt)]

The situation is better now that canvas uses EXTEND_PAD.

Bug 679257 is still causing unnecessary use of RepeatNone.
I guess using RepeatPad (fixing bug 679257) would be preferable to ARGB for software rendering, so that would seem a sensible step forward.

I'm a bit surprised that pre-NV40 cards don't support NPOT RepeatPad.  (Comment 2)
NV40 was launched in April 2004, but I don't know when NV30 was retired.

Comment 8

[Bas Schouten (:bas.schouten)]

Repeat none will be going away, slightly longer term we'll also be switching to Azure. I don't think we'll be investing anything in this.