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
pgpGxr6OTHYYO.pgp
Description: PGP signature
_______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
