[sugar] Cairo tile engine, and accessing 565 buffers from cairo and C

Carl Worth cworth at redhat.com
Mon Apr 16 16:24:49 EDT 2007


On Mon, 16 Apr 2007 16:08:31 -0400, Dan Williams wrote:
> typedef enum _cairo_format {
>     CAIRO_FORMAT_ARGB32,
>     CAIRO_FORMAT_RGB24,
>     CAIRO_FORMAT_A8,
>     CAIRO_FORMAT_A1
>     /* The value of 4 is reserved by a deprecated enum value.
>      * The next format added must have an explicit value of 5.
>     CAIRO_FORMAT_RGB16_565 = 4,
>     */
> } cairo_format_t;
>
> That doesn't really inspire confidence in the support of 565.

Sure. That's cairo_format_t which is used only in cairo's image
backend. And yes, the image backend *does* *not* support 565, (or any
other non-32-bit image format).

> > So you can certainly get 16bpp 565 surfaces manually as a _side_ effect
> > of create_similar on a 16bpp Xlib window if X is running in 16bpp
> > mode.

And you can also explicitly create 565 xlib surfaces, (or any other
X-supported format) by calling cairo_xlib_surface_create.

> In the end, this is all pretty pointless since we'll be hopefully moving
> to 24-bit color when we switch to the LX.

Which sounds very encouraging.

>                                          Again, I'm not trying to be a
> dick or spread lies, just trying to explain the limitations of working
> with Cairo as we've got it now.  Nothing personal.

I've never taken anything personally. I haven't had any negative
impressions of you, (and I hope my messages didn't suggest anything
other than that).

I'd also just things on the OLPC to work as well as possible, so I'm
only trying to explain how cairo can best be used for that.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20070416/2fa000df/attachment.sig>


More information about the Devel mailing list