[Xcb] double buffering

Jeremy A. Kolb jkolb at brandeis.edu
Wed Aug 23 11:14:12 PDT 2006

I don't believe that GLX double buffering depends on the DBE extension.


On Wed, 23 Aug 2006, Jamey Sharp wrote:

> On Wed, Aug 23, 2006 at 12:20:20PM +0200, Thomas Hunger wrote:
> > Does that mean that there is no "preferred" way for double 
> > buffering? So far I see two ways if dbe is deprecated:
> Bart's concern is that these are all extensions, so you can't count on
> any X server having them available. As a result, it would be useful to
> have a client-side library that maps general double-buffering operations
> onto whatever extension is available, or falls back to pixmaps and
> CopyArea.
> That said, I don't know which approach is "preferred", or if all the
> current mechanisms are considered lame. I'd add GLXSwapBuffers to the
> list of mechanisms to evaluate though.
> > 1) Rely on the composite extension and a composite client to
> >    redirect my drawing to off screen storage. Then send
> >    damage reports after redrawing. 
> There isn't yet a protocol to ask the composite manager to defer updates
> until you're done redrawing, though that's been discussed, so the
> composite extension doesn't actually buy you double-buffering right now.
> One of the double-buffer extensions may continue to have use in a fully
> composited world to help the server manage this.
> > 2) Create background pixmap. Problem: When should I free 
> >    the pixmap? Is there a way to create "soft-allocated"
> >    pixmaps which the server can claim when it needs space?
> >    I cannot find anything in the protocoll.
> I don't believe you can create "weak-referenced pixmaps" in X, no. I'm
> not sure why that's useful though: as long as you continue wanting
> double-buffering, you need that pixmap sitting around, right?
> > p.s. is this the wrong mailing list for this discussion? I 
> > found some related threads which did not really answer the 
> > question of double buffering:
> Yes, the xorg list is the right place to ask these general X technology
> questions; though you came to the right place for questions about XCB's
> extension implementations.
> --Jamey

More information about the Xcb mailing list