Re: Confused about GDKPixBuf/Cairo interaction



Le 19/02/2013 01:45, Rena a écrit :
On Mon, Feb 18, 2013 at 9:24 AM, Colomban Wendling
[...]

Well, my emulator gets the pixel data from gdk_pixbuf_get_pixels() and
writes into that buffer directly; that way it doesn't have to know
anything about GDK and can draw pixels by just writing directly into
memory, which saves a lot of overhead when it's rendering roughly 1.5
million pixels per second.
The emulator also supports Lua extensions which give scripts an object
wrapping the pixbuf and lets them draw on it.

OK I see.

If I use Cairo to draw shapes in the ::draw handler, that means I'd be
painting the pixbuf to the GtkDrawingArea's surface, then drawing
those shapes onto it? So the actual pixbuf contents wouldn't be
modified.

Yes.

That could lead to complications if a script wants to e.g.
produce a screenshot or read pixels back from the pixbuf, as it
wouldn't see anything it had drawn itself.

Indeed, nothing would be on the pixbuf but the original image.

I guess at best I'd need to
keep a separate surface around for scripts to draw on, and paint both
of those onto the GtkDrawingArea.

I guess that's 1 of 4 possibilities:

*) use Cairo directly, e.g. instead of creating a buffer compatible with
GdkPicbuf (or actually the GdkPixbuf buffer), create your own buffer
that uses a Cairo-compatible format and just write to that.  Then, you'd
just have to create a CairoImageSurface for that buffer and could
happily write to your buffer with Cairo.  That's probably the faster
solution.
Note that apparently Cairo don't have any 3-bytes format, even RGB24 has
a 4th unused byte.

*) convert (manually) data back and forth to and from Cairo (Edscott
Wilson pointed you a code doing this).  This has the overhead of 2
conversions each time you want to draw on the pixbuf (not counting the
conversion performed by GDK in the ::draw handler).

*) implement a Cairo surface that can draw directly to the pixbuf (e.g.
that does whatever conversion when performing drawings).  I don't know
how to do that but I guess it's feasible since Cairo already provides
various kinds of surfaces (and have a GObject layer).

*) handle 2 layers, the pixbuf and what's drawn on.  It may show som use
case (e.g. one could take a shot with or without additions) but probably
only makes things more complex.

Mainly I'm just confused at how GDK is using Cairo to do its painting,
but they use two different pixel formats.

I'm not 100% sure, but I guess they use the specific Cairo surfaces for
their targets (e.g. XLib surfaces on X11, Win32 surfaces on Win32 and
Quartz surfaces on OSX).  And when drawing pixbuf, they convert it
(using gdk_cairo_set_source_pixbuf()).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]