[PATCH 11/14] damageext: Xineramify (v6)
Keith Packard
keithp at keithp.com
Mon Dec 2 15:38:06 PST 2013
Adam Jackson <ajax at redhat.com> writes:
I've been reading code this afternoon, and I think your approach is
subtly broken.
PanoramiXDamageQueue traps the damage additions to screen 0, creates a
Dispatch callback and then waits until the request completes before
merging damage. Other screens call PanoramiXDamageAccumulate.
This assumes that damage will be delivered to all screens, which I don't
think is always the case as rendering which is clipped out will generate
no damage, and hence no callback.
I think you just want to have all of the screens hit the same callback
and add damage to the screen 0 instance; that way, it won't matter which
subset of the screens receive damage.
Independently, I'm not thrilled with a DIX-level DispatchCallback, but I
have to admit that I don't have a better solution -- adding it down
inside panoramix would mean touching every single rendering function to
process the queued damage, and there's no other place between the
panoramix wrapper and Dispatch.
--
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20131202/2f3f134b/attachment-0001.pgp>
More information about the xorg-devel
mailing list