[PATCH 2/2] damageext: Xineramify (v4)
ajax at redhat.com
Wed Oct 9 10:41:34 PDT 2013
On Wed, 2013-10-09 at 10:00 -0700, Keith Packard wrote:
> Adam Jackson <ajax at redhat.com> writes:
> > Enh. I'm not convinced. damageDamageAppend already clips based on
> > subwindow mode, so you're either getting the borderClip if
> > IncludeInferiors - thanks to NotClippedByChildren - or the clipList
> > which includes children. And since we're in Xinerama, borderClip is
> > already clipped to the containing ScreenRec's geometry.
> I haven't looked at the rest of the patch -- are you fixing that so that
> damage is clipped to the union of the borderClip regions?
Well, no, but it could never matter. The per-screen reports are already
clipped to their respective borderClips (which, as noted, are clipped to
their containing root), and then I'm unioning them all together on
screen 0's DamagePtr. The union of per-root-window borderClips can't
exceed the Xinerama view of the border clip by definition.
> > This is sort of true of non-Xineramified damage as already written, no?
> > We're already not wrapping MoveWindow and friends in miext/damage.
> > Subtract would magically trim off bits that had been configured away in
> > the re-emitted report, but the 'parts' region is the region before
> > reconfigure.
> Right, the clip intersect in Subtract ends up fixing any potentially
> overreported damage before the client sees it.
My point was that they can see it by inspecting the parts region after a
Subtract. But if that's intentional...
> > It's just "union of borderClip for all backend windows", right? Or at
> > least that'd be consistent with how DamageSubtract already clips in the
> > non-xin case. That seems easy enough.
> It's either that or fix the damage to be 'correct' across window
> configuration changes, I think. Either would work, doing it in Subtract
> would keep things the same as the single-screen case today, and save a
> bunch of frobbing during configuration changes.
Doing it in Subtract seems both much simpler and much saner than trying
to wrap configuraton changes, yeah.
More information about the xorg-devel