[cairo] Frame Buffer and Special Pixel Formats

[Klaus Stehle]

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

The curious thing is that a lot of the programming work is already
done for these formats in the pixman library.

Cheers
Klaus

[Behdad Esfahbod]

Post by Klaus Stehle
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
we do not plan on always guaranteeing that cairo will be able
to draw to these formats.
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.

behdad

Post by Klaus Stehle
The curious thing is that a lot of the programming work is already
done for these formats in the pixman library.
Cheers
Klaus

[Mike Emmel]

Post by Behdad Esfahbod

Post by Klaus Stehle
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
we do not plan on always guaranteeing that cairo will be able
to draw to these formats.
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.

Correct generally unless you need to use the image backend you should
use the platform
api's to create the cairo surface for "weird" formats.

So for directfb you would create the directfb window/surface in the
alternative format then create the cairo surface.

Thus via

cairo_directfb_surface_create (IDirectFB *dfb,IDirectFBSurface *surface)

A bazillion formats are supported :)

Post by Behdad Esfahbod
behdad

Post by Klaus Stehle
The curious thing is that a lot of the programming work is already
done for these formats in the pixman library.
Cheers
Klaus

--
behdad
http://behdad.org/
"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759
_______________________________________________
cairo mailing list
http://cairographics.org/cgi-bin/mailman/listinfo/cairo

[Klaus Stehle]

Date: Wed, 29 Nov 2006 13:54:43 -0500
Subject: Re: [cairo] Frame Buffer and Special Pixel Formats

Post by Klaus Stehle
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
we do not plan on always guaranteeing that cairo will be able
to draw to these formats.
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

[Øyvind Kolås]

Post by Klaus Stehle

Post by Behdad Esfahbod

Post by Klaus Stehle
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.

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.

If I had this need, something I don't and I am choosing not to focus
on, I would extend babl [1] with the capability to use data types that
are not a multiple of 8bits
long, it already supports different data types in a single format.

On top of the API provided by babl creating a cairo "backing buffer"
that a different format can be requested from is quite simple, and
optimized conversions for frequently occuring pixel formats can be
added based on what formats are acutally
needed.

Another option would be to use the embedded pixel format conversion
routines contained in something like ffmpeg, directfb, libmerlin
(gavl), clanlib or some other already existing solution.

1: http://pippin.gimp.org/babl/

[Carl Worth]

Post by Behdad Esfahbod
My understanding is that we don't want to clutter the image-backend API.

It's not just a question of avoiding API clutter. I think a bigger
issue is the desire to have an optimized software rendering
implementation. With the very small number of image formats that cairo
provides, (as well as the rich set of operators), there's already
fairly large combinatorial explosion going on inside the rendering
code.

So it doesn't make sense to add new image formats unless we're also
committed to implementing as much optimization in the rendering for
those as we plan to implement for all other image formats.

If instead, the idea is to just add some conversion before and after
each operation, then it doesn't make sense to provide this as a
"supported" image format in cairo. It would be more efficient to delay
the conversion until an entire set of operations is performed, (such
as a complete frame in an animated sequence). And doing conversion at
that point should be possible with the interfaces in cairo
already. (One thing that might be needed is a way to find out the
region that is dirtied by a sequence of operations so that no more
data is converted/copied than necessary).

Does that make sense?

-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.freedesktop.org/archives/cairo/attachments/20061204/46a7017d/attachment.pgp

[Owen Taylor]

Post by Carl Worth

Post by Behdad Esfahbod
My understanding is that we don't want to clutter the image-backend API.

It's not just a question of avoiding API clutter. I think a bigger
issue is the desire to have an optimized software rendering
implementation. With the very small number of image formats that cairo
provides, (as well as the rich set of operators), there's already
fairly large combinatorial explosion going on inside the rendering
code.
So it doesn't make sense to add new image formats unless we're also
committed to implementing as much optimization in the rendering for
those as we plan to implement for all other image formats.

While this makes sense in general (for 24bpp formats, say), for things
that are actually common frame buffer formats like rgb565, it makes
less sense, since we are actually basically sharing the code used
in the X server... we already have optimized rgb565 code.

- Owen

[Klaus Stehle]

[ ... ]
If instead, the idea is to just add some conversion before and after
each operation, then it doesn't make sense to provide this as a
"supported" image format in cairo. It would be more efficient to delay
the conversion until an entire set of operations is performed, (such
as a complete frame in an animated sequence). And doing conversion at
that point should be possible with the interfaces in cairo
already. (One thing that might be needed is a way to find out the
region that is dirtied by a sequence of operations so that no more
data is converted/copied than necessary).
Does that make sense?

Yes, it does ...
and it should work fine, if there was a hook, a callback function,
which is called by the image surface whenever something has been
dirtied, so the conversions/copies can be triggered automatically.
Thus the "support" of any pixel format could be simulated :-)


Klaus