[PATCH 11/14] damageext: Xineramify (v6)

[Keith Packard]

Adam Jackson <ajax at redhat.com> writes:

> No.  Accumulate -> DamageReportDamage on screen 0 -> Queue.  Even if
> clipping means there's no damage to screen 0's logical aperture, screen
> 0's DamageExtPtr tracks the whole protocol screen, and its callback
> always gets invoked.

Oh, right, it's calling DamageReportDamage on the screen 0 damage
object. That should work. I didn't expect that, which is why I missed
it.

> Yeah, I didn't like it either.  I had hoped to be able to just do the
> event emission from screen 0's callback, but not all the rendering paths
> do FOR_NSCREENS_BACKWARD.  And in a previous iteration of this patch I'd
> used FlushCallback, but WriteEventsToClient can itself flush so that can
> be infinite recursion.

Oh. Is there some reason that just calling DamageExtReport directly from
the screen 0 handler every time wouldn't work just fine? You'll get
multiple damage events for windows which span screens, but clients
should deal with that just fine. Would greatly simplify your code, at
the cost of not generating minimal damage reports.

-- 
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/20131203/40927c6a/attachment.pgp>