[cairo] drawing on and reusing an off-screen image surface

[Peter Groves]

On Mon, 03 Dec 2007 11:06:06 -0800
Carl Worth <cworth at cworth.org> wrote:

> On Mon, 3 Dec 2007 12:31:58 -0600, Peter Groves wrote:
> > So what I'm hearing is that manipulations with raster data are typically
> > best done on the gtk side. Is this a safe generalization to live by?
> 
> I'm not sure what you mean by "gtk side" at all. You should definitely
> feel free to use cairo for any operation it can perform.
> 
> > I ask b/c next I'll be drawing small glyphs with cairo and then making a
> > few hundred copies of each to make a large data plot, and was going to use this
> > same basic idea (draw to an image, then copy the image onto the background).
> 
> Yes, that's a fine idea. And you can use cairo to do that.
> 
> In cairo terms, I'd rephrase your approach as "draw to a surface, then
> copy the surface", and then recommend that for this intermediate
> surface you should use a "similar" surface rather than an "image"
> surface for better performance.
> 
> And that is a good generalization. A similar surface should be
> preferred unless an image surface is actually required, (which should
> only be required if you need to do direct, non-cairo manipulation of
> the image data).
> 
> Does that make any more sense?

It's getting clearer. Somewhere I got it in my head that any time a cairo
operation told gtk to display a surface, it would require the whole rasterized
surface to be copied. This would happen even if it was the surface from
gdk_create_surface. But instead the surface from gdk_create_surface will draw
directly on a pixel buffer, which gtk will display directly (no copying of the
pixel data needed). Right?

Why is the surface from surface_create_similar more efficient than an image 
surface? Why would it matter when it's being used as an intermediate small 
image to be copied onto the image that will actually be displayed? Is it because translations between types of pixel representations won't be needed?

Peter
-- 
http://petergroves.com