Future of shadow and shadowfb

[Dave Airlie]

On Thu, Oct 25, 2012 at 7:13 AM, Adam Jackson <ajax at nwnk.net> 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.

Well damage does that anyways for the sw cursor code so it shouldn't
be a major problem.

>
> 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, 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
> - merge that with shadow since they'll then be largely equivalent
> - keep the external API intact since it's easy enough
> - hack loader to alias 'shadow' and 'shadowfb' together
>
> Anything I'm missing here?

You thinking off doing updates on a timer instead? like I did wonder if we were
better syncing to updating closer to refresh rate, as it may allow
more rendering and
damage to coalesce.

Dave.