Adam Jackson <[email protected]> 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. -- [email protected]
pgpLsL_WlFTPc.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
