[cairo] Bringing back the dead... RGB16_565
David.Hill at Sun.COM
Thu May 17 06:15:49 PDT 2007
the mobile project I have been working on is coming back out of the
hiatus is has been in, with me taking over ownership of the part that
uses Cairo. I see that while we were in hibernation, a decision was made
to deprecate RGB16_565. I have attached to the end of this email a
relevant portion from the mailing list archives. Needless to say, I was
a bit bummed by this as I was telling people how great Cairo was working
In our application, we render only to a surface, and so some of the
other uses only interest me in that they are causing you guys to exclude
it as a supported format. Writing to X or PNG have no application for
me, except perhaps as development/testing vehicles on the desktop.
So I asked the Boss if I could help out on addressing some of the 565
concerns and contributing back, and he is amenable to the idea. So next
I need to scope out the work items and get the nod from the Cairo team
before I get coding and supplying diffs.
So, given Carl's work list as a starting point...
This is easy, I would perform the render to a 24RGB and then save it out
at a minimum, or convert the scan lines on the fly in the
compressor(there are hints in the png docs I need to try). Again, this
is useful mostly as a testing mechanism in my view, so the performance
is secondary to implementation speed.
Do you really need support for all types on all platforms ? I have not
done an in depth study of the code, but I do find a couple of places
if (format != CAIRO_FORMAT_RGB24)
/* XXX handle these eventually
format != CAIRO_FORMAT_A8 ||
format != CAIRO_FORMAT_A1)
that lead me to the conclusion that not all formats make sense to all
back ends. If xlib support is needed for testing purposes that may make
sense to do more than just fail gracefully.
Again, do we really need Xlib support? I have been dinking around with X
for more than a few years (though Keith Packard has me beat) and can't
ever recall seeing a 565 format (Though Dec did have "true color" format
in 8 bits-332RGB, never did figure out why). Given that, unless there is
a compelling test case reason, I don't see why the library can not just
assert failure when it is not supported/appropriate.
X. What other areas is this impacting that I would need to address ?
For those insatiably curious, the project I am on is the former SavaJe
Mobile OS, now acquired and rebranded as Sun's JavaFX Mobile.
From the cairo archives, Carl wrote:
On Sun, 10 Sep 2006 21:02:22 +0200, Jay Vaughan wrote:
> .. count me in the "hand raised to know what is needed to *implement*
> RGB565" rather than remove it, also .. I mean, there's lots of places
> such a format, plus cairo, are useful (hand-held LCD devices running
> Linux galore ..)
The drawing code currently in pixman should already support rendering
to an RGB565 format image. The parts of cairo that do not currently
support 565 can be found by compiling current cairo with a recent
version of gcc and looking for the warnings that complain about
CAIRO_FORMAT_RGB16_565 not being handled in a switch statement. The
current cases are:
1. cairo-png.c:write_to_png - Need code to write an RGB565
image out as a PNG file. The easy way would be to
cairo_paint to a RGB24 surface first and then write that
out with the existing code. The hard way would be to
actually emit a 16-bit PNG file.
2. cairo-xlib-surface.c:_CAIRO_FORMAT_TO_XRENDER_FORMAT - In
this case, it's a matter of chasing down an
XRenderPictFormat for the RGB565 cairo format. This is
harder than the current code which uses
XRenderFindStandardFormat since RGB565 is not a standard
Render format. A functional, (though uninteresting), thing
to do here would be to just fail and let the caller use an
image fallback. A more interesting approach would be to
chase down a 16-bit visual (if available) in the X server,
and then use XRenderFindVisualFormat with that.
3. cairo-xlib-surface.c:_cairo_xlib_surface_add_glyph - I
haven't chased down what would need to happen here. I'll
leave that as an exercise for the reader.
One other thing that should be kept in mind with adding support for
RGB565 is that it would put an additional required format on what
would need to be implemented in any pixman replacement.
More information about the cairo