Future of shadow and shadowfb

[Connor Behan]

On 25/10/12 12:00 PM, michel at daenzer.net wrote:
> 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? 
If you merge shadow and shadowfb and it turns out to be detrimental to
r128, I'm sure I can update it to use damage directly. This commit
<http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=d43ad88fa3913437f6987ab5ab46a38f0cb555a8>
for radeon would be just as easy to perform on r128.
>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20121025/0db47ca7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20121025/0db47ca7/attachment.pgp>