550845 - getImageData() on Linux proportional total canvas size

Status: UNCONFIRMED

(Core :: Graphics: Canvas2D, defect)

Description

[Roland Bär]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2) Gecko/20100222 Ubuntu/10.04 (lucid) Firefox/3.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2) Gecko/20100222 Ubuntu/10.04 (lucid) Firefox/3.6

On Linux, getImageData() typically takes 1000 times longer, then on Windows or MacOS, or with competiting browsers.
Typical usage, get a very small part (size of mouse pointer) out of a big image (e.g. screenshot). 

Reproducible: Always




The results of various browser tests are here:
http://www.verifysoft.eu/measure.txt

Note: The Linux specific tests have been done with only 100 iterations, but the
good (non-Linux and non-Firefox) tests have been done with 10000 iterations.

More, this seams to be a Unix/X11 related problem, as some additonal ad-hoc tests with a BSD live CD have shown..

Comment 1

[zug_treno]

Duplicate of/related to Core Bug 519400 comment 7?

Comment 2

[Roland Bär]

Attachment: Getting 1 pixel with getImageData() 100 times on a 640x480 canvas

test-perf.html as stand-alone test. The issue that it depends on concrete canvas size is not covered here. A 640x480 canvas should be typical for intended use on screen-shots, some measurement results:
EEEPC 701, Ubuntu, Firefox 3.6: 3365 ms.
Parallels virtual machine, running XP on a Macbook with Firefox 3.5.8: 2ms
Macbook Safari: 0ms 
Minefield 3.7a3pre (same EEEPC): 3755ms.

Comment 3

[Roland Bär]

(In reply to comment #1)
> Duplicate of/related to Core Bug 519400 comment 7?

Bug 519400 addresses both getImageData() and putImageData(). I have the
impression, that we have (no longer) issues with putImageData(). 
The concrete problem seams to be not related to (un)premultiply lookup tables, for which that bug was closed, once solved.
So, most likely related, but #519400 addresses multiple issues, all minus one solved.
The question is, why here (Linux|Unix/X11 only), getImageData() internally seams to fetch the whole canvas, not only the part requested. 

Roland "Test-tools" Bär

Comment 4

[Boris Zbarsky [:bzbarsky]]

When running on X11, the canvas backing store is stored on the X server, not in the client.  When you call getImageData, we have to fetch the pixmap from the X server first.  This is what takes so long.

The benefit of storing the backing store server-side is you get Render-accelerated painting when you use the canvas APIs (so you get performance that's actually pretty comparable to what you get with Direct2D on Windows).  The drawback is that getImageData is a lot slower, since it has to at least talk to the X server, and possibly do a readback from the video card....  Pretty much all the time cost is in the latency of these operations, not the actual work needed to get the 1px of image data out of the resulting memory region.

There are existing bugs on maybe storing the canvas backing store client-side when running on X11, but the issue is that it significantly slows down some other things.  Maybe we should fall back to client-side storage after the first getImageData call or something.  :(

Comment 5

[Krzysztof Kotlenga]

In case anyone's wondering, setting MOZ_CANVAS_IMAGE_SURFACE environment variable (see Bug 568526) makes things acceptably fast - change from 119 ms down to 1 ms.

Our use case involves relatively small reads from a 2048x2048 (gl.MAX_TEXTURE_SIZE) 2D canvas (basically a texture source for gl.texImage2D/gl.texSubImage2D).

Comment 6

[Roland Bär]

I can confirm, that 
export MOZ_CANVAS_IMAGE_SURFACE=1
firefox&
significantly and dramatically improves the performance.

Comment 7

[prattler26]

about:config -> gfx.xrender.enabled = false

fixed the issue for me