On Fri, 2010-05-07 at 11:46 -0700, Keith Packard wrote: > On Fri, 07 May 2010 10:30:16 -0400, Adam Jackson <a...@nwnk.net> wrote: > > I can _almost_ see the justification for this, but it sure feels like it > > belongs in Composite not RANDR. > > Yeah, it could go in Composite too. The whole reason I added this > request is so that we could use the existing GL semantics for double > buffering on windows, but Ian suggests that we might just as easily > define semantics for double buffering on pixmaps and avoid this whole > issue. Perhaps that would be a better plan?
I suspect that'll be cleaner. I do like the idea of SetWindowPixmap, it's just subtle, and seems out of scope for CRTC pixmaps. The rest of this is mere pedantry... > > What happens when it's unmapped? > > An unmapped window doesn't draw anything anywhere. What I was getting at was more like: If you SWP, unmap, and remap, do you keep the same old storage? > > Which of the two drawables does the > > application render to, and what happens if it renders to the other > > one? > > Just like the existing Composite 'NameWindowPixmap', you've got two > names for the same drawable now; rendering can occur on either one. That's not quite true, or at least, the illusion is not complete. If I have an Automatic window, name its pixmap, and draw to the pixmap, nothing will show up on screen until some side effect happens; the damage listener is on the Window. Likewise most compositors listen for damage on the Window, not the Pixmap. More broadly, Damage doesn't know the two names are the same drawable. It might make sense to have Damage always listen on the window pixmap and translate coordinates if the listener was on a Window name. - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
