[cairo] glitztest and pbuffers

[David Reveman]

On Wed, 2004-05-26 at 18:41 -0700, Jon Smirl wrote: 
> I'll dig through everything and try to figure out why it is making the
> background surface current.
> 
> --- David Reveman <c99drn at cs.umu.se> wrote:
> > glitz_surface_read_pixels (surface, &pixels);
> > image = cairo_image_surface_for_data (pixels);
> > pixman_drawing_operation (image);
> > glitz_surface_draw_pixels (surface, pixels);
> 
> I think we need to hide the surface types from the application and just pass in
> hints. So instead of glitz_glx_surface_create_for_window() and
> glitz_glx_surface_create() you just call surface_create_for_window() and
> surface_create().
> 
> surface_create_for_window() would work down a prioritized set of backends - glx,
> xrender, xlib. You can use a hint to force one further down the list to the top,
> but it's only a hint.
> 
> surface_create() would work the same. It would try pbuffer, pixmap, libpng.
> 
> surface_create_readonly() would be used for read only images and these would be
> mapped directly to textures.
> 
> So in my case offscreen surfaces would automatically be made with pixmaps and
> not do the read pixels/write pixels. The image would just stay a pixmap until
> you copy it to the window surface or readonly_surface. It's not clear from your
> example how often you read/write pixels.

Right now it's done for every drawing operation. This is why offscreen
drawing is extremely inefficient with the gl backend when pbuffer
support is missing. I been planning to add an image surface buffer to gl
backend surfaces which doesn't support offscreen drawing. The image data
will then only be flushed to the glitz surface when actually needed.
This will fix the efficiency problem and make the gl backend really
useful for offscreen drawing, even though pbuffer support is missing.
Imagine a scenario where an application is doing a bunch of drawing to
an offscreen surface and then use it as a pattern or with show_surface,
offscreen drawing speed will be ok (pixman speed), pattern and
show_surface will be OpenGL fast.

> 
> Another solution that may work but I haven't tried is to use the backbuffer for
> offscreen drawing. You copy the texture to the backbuffer, use the hardware to
> draw on it, and then copy it back to the texture. Defer the copy back until
> something else needs to use the backbuffer.

I don't like this idea. It means that an offscreen surface must be linked to an
onscreen surface in some way, we don't want that. And even more
importantly, the backbuffer must be fully viewable (try drawing to a GLX window's
backbuffer when the window is covered by another window, you'll get nothing).

However, for a glitz mesa-solo backend this might be considered, as we'll then
control the complete screen. For the GLX backend, No.
 
-David