[cairo-bugs] [Bug 31603] Performance regression when drawing a CAIRO_FORMAT_RGB24 onto a xlib surface with 16bit

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=31603

--- Comment #5 from Siarhei Siamashka <siarhei.siamashka at gmail.com> 2010-11-13 12:38:50 PST ---
(In reply to comment #4)
> Hmm, it is also trivially possible to extend the PutImage routine to do the
> conversion using pixman where possible which would be the preferred method.

Right, I also tried to suggest the same here (but did not have time to
implement, test and benchmark it myself):
http://lists.cairographics.org/archives/cairo/2010-November/021057.html

That slow code in cairo also wastes a lot of time on doing dithering, but
considering that 16bpp color depth is typically used on very resource
constrained devices, not doing that should be reasonable. Also dithering is
very important for the formats where very few bits are used for color
components (like 1, 2 or 4), but for RGB565 format, banding is less noticeable
even though it of course exists.

I'm worried that the proposed patch is just a band-aid and is only going to
improve performance from abysmal to just poor on that hardware. But having
detailed profiling reports may reveal some of the things which can be improved
(PXA270 supports IWMMXT SIMD instructions, so the most critical hotspots in
pixman can be improved a lot). For example, as I mentioned before, a properly
optimized x8r8g8b8->r5g6b5 conversion is faster than a simple
x8r8g8b8->x8r8g8b8 copy on all the hardware that I have seen (just because it
needs less memory bandwidth). But this may be not the case with just generic C
code, so somebody may be tempted to prefer whatever works faster with the
current implementation and ignore the possibilities to get even more
performance with a little bit more work. Anyway, this all can be benchmarked to
get a better understanding about what's going on there.

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