[cairo-bugs] [Bug 10208] Cairo image rendering very slow on devices with depth 16 (and without hardware XrenderComposite)....

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=10208


daniel.amelang at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Comment #4 from daniel.amelang at gmail.com  2007-05-02 13:48 PST -------
I'd like to close this bug, as it's really just a result of several
misunderstandings which were hopefully cleared up in this thread:

http://lists.freedesktop.org/archives/cairo/2007-March/010008.html

Here are the general take-home lessons:

1) You shouldn't be compositing with a 16-bit surface in cairo's image backend
(your attached oprofile report shows that you are). The cairo image backend is
not meant to be used with 16-bit images. You'll want to look into whatever is
making this happen. You probably want to convert your images into xlib surfaces
and then just deal with compositing xlib surfaces together. This approach also
pushes the compositing down into the xserver where it will (should) be faster.
As of this moment (cairo git vs. xorg git), it will be significantly faster on
the xserver side (see the patches to xorg that I refer to at the bottom of this
message).

2) You say that the 32->16 bit color conversion should be cached. That's
doesn't make sense, at least not the way you seem to mean it. Perhaps what you
want is to turn your images into 16-bit xlib surfaces and do compositing on
those, as suggested above? Of course, you'll lose your alpha channel, but any
32->16 bit "caching" would have that same disadvantage.

3) As pointed out in the mailing list thread, the "missing paint operation"
isn't a cause for slowdown.

4) As pointed out in the thread, if you can composite your surfaces together
once and just scroll that final result, do that instead. The "final result"
that I'm referring to would be an xlib surface that is the result of
compositing your two surfaces.

5) You might want to look into why fbFetchTransformed is being called. Right
now, compositing+transformation can be a cause of slowness. If you're just
translating the surface, maybe you can just try a set_source_surface with the
offset. I'm really just guessing here, as you haven't provided any code for me
to look over.

FYI, I have submitted 2 patches to xorg that speed up 32-bit argb OVER 16-bit
rgb that might help you here:

http://lists.freedesktop.org/archives/xorg/2007-April/023763.html
http://lists.freedesktop.org/archives/xorg/2007-April/024286.html


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.