Proposal for per-CRTC pixmaps in RandR

[Adam Jackson]

On Fri, 2010-05-07 at 11:46 -0700, Keith Packard wrote:
> On Fri, 07 May 2010 10:30:16 -0400, Adam Jackson <ajax at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100507/24b76c95/attachment.pgp>