[cairo] Frame Buffer and Special Pixel Formats

[Klaus Stehle]

On Wed, 29 Nov 2006, Behdad Esfahbod wrote:

> Date: Wed, 29 Nov 2006 13:54:43 -0500
> From: Behdad Esfahbod <behdad at behdad.org>
> To: Klaus Stehle <klaus.stehle at uni-tuebingen.de>
> Cc: cairo at cairographics.org
> Subject: Re: [cairo] Frame Buffer and Special Pixel Formats
> 
> On Wed, 2006-11-29 at 01:49 -0500, Klaus Stehle wrote:
> > Hallo Cairo,
> > 
> > There is a need to have a simple cairo frame buffer surface,
> > which can handle all that special pixel formats like
> > 2-byte-RGB16_565, 3-byte-RGB24_888 etc. etc.
> > because a lot of graphic adapters require such odd formats.
> > 
> > Ok. There is the cairo-image-surface. But I read in the source
> > code things like this:
> > 
> >      cairoint.h:
> >      we do not plan on always guaranteeing that cairo will be able
> >      to draw to these formats.
> > 
> >      cairo-image-surface.c:
> >      We don't really want to advertise a cairo image surface that
> >      supports any possible format.
> > 
> > 
> > Now the question: What are the real reasons behind those
> > "we don't want" or "we do not plan" etc.?
> 
> My understanding is that we don't want to clutter the image-backend API.
> For framebuffers, I think the idea is to use the directfb backend.  That
> probably supports a variety of formats already.
> 
Oh, I asked this question because I'm searching for a *SIMPLE*
alternative for directfb.
A simple interface means: data buffer, width, height, format/bpp/stride,
and it would be nice if cairo as a basic graphics library supported
such an interface.

Furthermore there is a gtk+ backend for linux frame buffers
which does NOT use directfb. This backend could be reanimated
with a cairo that supports simple frame buffers.

You say, the cairo image surface shouldn't be cluttered by these ugly
pixel formats.
What about a new "cairo_frabu_surface", a cairo frame buffer surface?




Cheers
Klaus