Re: rendering-cleanup

[Havoc Pennington <hp pobox com>]

Hi,

On Tue, Aug 3, 2010 at 5:14 AM, Yasushi SHOJI <yashi atmark-techno com> wrote:
> I assume I can't do the following:
>
>        pixbuf = gdk_pixbuf_get_from_drawable(NULL,window,NULL, ...);

Oh, this is really not what you want to do at all - getting an image
or pixbuf from drawable is actually going out to the X server and
"screenshotting" the current pixels, which is typically slow compared
to any drawing you might be doing. This would be a performance
negative. the good news is, if you were doing this and didn't need to,
then fixing this will give you back more performance than you'll lose
doing a 565-to-888 conversion perhaps.

To draw, you'd want to just create an image or pixbuf instead of
getting one with pixels from the drawable. In cairo it's
cairo_image_surface_create().

Basically you'd cairo_image_surface_create(), then draw your 565 (it
would be better to just draw directly to 888 or draw with cairo
functions, of course, if possible, but assuming you want to avoid
redoing your drawing code). Then you'd cairo_image_surface_get_data()
and manually convert 565 to the 888 surface. Then
cairo_set_source_surface() and cairo_paint(). It's best to avoid
GdkPixbuf just for drawing, just use Cairo.

To get a 565 buffer just allocate it, 16 bits per pixel, so
g_malloc(rowstride * height * 2), right. The rowstride can just be the
width to keep things simple.

> it just that my hardware platform does not have a powerful CPU like
> desktop nor server.  and if I know that X is RBG565 format, I want to
> use the exact same format to save some cpu cycle.

To get the absolute fastest performance you'd probably have to use
Xlib and XImage directly. Though in an ideal world, if you created a
cairo surface for a 565 drawable (with gdk_cairo_create()) and could
then draw with cairo operations instead of with direct pixel access,
maybe cairo would never go through 888. But I don't know whether cairo
has that optimization, and of course it would depend on using cairo
drawing operations instead of direct pixel access.

Havoc