[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.
Jeremy
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