[cairo] RGB Buffer to Cairo Surface
cworth at cworth.org
Mon Apr 14 10:24:09 PDT 2008
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:
pixel = (A << 24) | (R << 16) | (G << 8) | (B);
> colorBar = cairo_image_surface_create_for_data(rgbbuf,
> CAIRO_FORMAT_RGB24, width, h, stride);
> 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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080414/d98da7ec/attachment.pgp
More information about the cairo