[cairo] Bringing back the dead... RGB16_565

[David Hill]

Hi,
  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 
for us.

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...
1. cairo-png.c:write_to_png
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.

2. cairo-xlib-surface.c:_CAIRO_FORMAT_TO_XRENDER_FORMAT
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 
like this:
cairo-glitz-surface.c:
   case CAIRO_FORMAT_RGB24:
       ASSERT_NOT_REACHED;
       break;
cairo-win32-surface.c:
   if (format != CAIRO_FORMAT_RGB24)
       return NULL;
/* 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.

3. cairo-xlib-surface.c:_cairo_xlib_surface_add_glyph

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 ? 
Testing perhaps?

For those insatiably curious, the project I am on is the former SavaJe 
Mobile OS, now acquired and rebranded as Sun's JavaFX Mobile.

Dave Hill


-----------------------------------------------------
 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.