Future of shadow and shadowfb

[Michel Dänzer]

On Mit, 2012-10-24 at 17:13 -0400, Adam Jackson wrote: 
> Did you know we have two of these?  Can we have only one of these?
> 
> I'd like to merge them together, one way or another, but there are some 
> slight semantic differences.  shadowfb gives you hooks for both pre- and 
> post-rendering callbacks.  Exactly one driver uses this, vmware, for 
> what looks like tearing down and putting back up the cursor.  I'm 
> reasonably sure that could be better handled, but it's also easy enough 
> to preserve.
> 
> More interestingly, shadow batches updates until BlockHandler, whereas 
> shadowfb is immediate.  I would expect shadow's performance to be better 
> in the typical use case since it would reduce overdraw.  I don't know of 
> any drivers that _depend_ on shadowfb giving an immediate callback,

I wonder if e.g. xf86-video-r128's page flipping support doesn't depend
on immediate callbacks. Otherwise, can't the second page display stale
non-GLX bits?


> but conversely BlockHandler isn't exactly a great interface for periodic 
> updates, since it gets called on no particular schedule.
> 
> So my thinking is:
> 
> - port shadowfb to damage instead of handrolling it

That sounds like a good idea anyway.


> - merge that with shadow since they'll then be largely equivalent
> - keep the external API intact since it's easy enough

Maybe the merged module could preserve immediate vs. delayed updates
depending on which external API is used.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer