[Webkit-unassigned] [Bug 41682] Certain page elements cause XGetImage and software fallback rendering

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jul 19 00:33:59 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=41682





--- Comment #8 from Ariya Hidayat <ariya.hidayat at gmail.com>  2010-07-19 00:33:59 PST ---
Created an attachment (id=61930)
 --> (https://bugs.webkit.org/attachment.cgi?id=61930)
potential workaround

Here is my analysis (the pixel metrics refer to my reduced test case).

We try to fill an area, e.g. 400x400 pixels with a repeated pixmap (as the background). Usually this is not a problem, but since the pixmap is very big, e.g. 48x800 , Qt X11 hits the inefficient code path to handle that as pattern fill.

In my proposed fix/workaround, this is solved by painting the pixmap repeatedly ourselves. We detect if the rectangle can be filled by the pixmap just a few times in a horizontal direction. If yes, there is no need to use the pattern fill approach.

Have a look at the patch and see if this works for you. If performance is still problem due to the use clipping, I can unroll the clipping and set up the source and target bounding boxes ourselves (but I'd save that part until it's absolutely necessary, readability issue).

Technically the fix should work everywhere, not only X11. If some graphics system (possibly Open GL) shows slight speed degradation, we can put #ifdef around the special case. However, I can't imagine where a small number of manual pixmap repeats is much slower vs pattern fill with a huge pixmap texture.

Note: the patch is not for review, I just want to gather early feedback first.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list