[cairo] RGB Buffer to Cairo Surface

[Carl Worth]

On Mon, 14 Apr 2008 17:44:26 +0200, "richard boaz" wrote:
> Also, special care must be taken if the code is expected to run on multiple
> platforms since the ARGB buffer is required to be in native endian format.
> (imho, this is something that should be shielded from the caller, but there
> you go.)

A simpler way to code this, (that doesn't require any endian-test is:

	uint32_t pixel;

	pixel = (A << 24) | (R << 16) | (G << 8) | (B);

> colorBar = cairo_image_surface_create_for_data(rgbbuf,
>             CAIRO_FORMAT_RGB24, width, h, stride);
> free(rgbbuf);
...
> Playing around, it seems that the rgbbuf used to create colorBar cannot be
> freed until you're done with the colorBar surface itself.  This is not
> stated in the documentation, so can cause serious head-scratching.  Anyone
> know why the rgbbuf is required to hang around?

The whole point of cairo_image_surface_create_for_data is that cairo
is rendering to a buffer that you allocated and are holding onto, (so
that you can then directly read the cairo-rendered content out of the
buffer again).

Alernately, you can use cairo_image_surface_create which allocates the
buffer internally, (and computes the stride of course). You can still
get a pointer to the buffer with cairo_image_surface_get_data for
stuffing your own content in.

Oh, and answering some of your previous questions:

> >    1. I do not find a v1.6 of Cairo available from the download site.
> >    Is it really true?  The documentation preceeds the release of the software
> >    itself?  (wow...)  Or am I missing something?

Cairo 1.6 is there now, (as hopefully you've seen). The reason the
documentation was saying things like "since 1.6" is that 1.6 really is
the first *release* to have the cairo_format_stride_for_width
function. You were seeing this function in a pre-release,
in-development *snapshot*, (1.5.x), but the documentation won't ever
refer to an in-development version like that.

> > More generally, it seems that programmatically generating a RGB buffer for
> > conversion to a Cairo surface is not obvious (to me, yet).  Am I wrong about
> > this?  Is there a more straightforward way of doing this I haven't yet
> > teased from the documentation?  Is there a different way of accessing the
> > individual pixels of an RGB buffer I am unaware of that would allow me to
> > fill them up individually without having to make wrong assumptions and
> > guesses?

I'm sorry this wasn't more obvious to you. We can definitely put a
good example on the cairo website, (in fact, anyone can as it's a wiki
that can be edited by anyone that simply registers).

Would you be interested in helping with that so that hopefully more
people don't struggle similarly in the future?

-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.cairographics.org/archives/cairo/attachments/20080414/d98da7ec/attachment.pgp