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

[Keith Packard]

Adam Jackson <ajax at redhat.com> writes:

> I can think of two semantic issues that would introduce.

So, my thinking was that you'd configure the screen 0 damage object
precisely as in the single screen case (and, in fact, leave it calling
DamageExtReport), and then you'd configure the non-0 screens to be
DamageReportRawRegion, and have their damageReport callback translate
the region back to screen 0 space, and call DamageReportDamage on that,
then empty the damage region. This would result in having
DamageReportDamage get called precisely as if multiple sequential rendering
operations were performed on screen 0, which would apply the appropriate
damageLevel modifiers before calling DamageExtReport.

> NonEmpty reports would effectively hear multiple edge triggers for the
> same logical event.

DamageReportDamage would filter out subsequent regions and not call
DamageExtReport after the first region was added, for whatever screen
that region was added on.

> BoundingBox is worse, because the event stream would become nonsense.
> Imagine a 100x100 window, straddling horizontally adjacent screens, such
> that a 50x100 strip is on each.  A client creates a Damage on it.  The
> initial report kicks back with two events, one saying the bounding box
> is 50x100+0+0, and one saying it's 50x100+50+0.

Because you're accumulating damage on the screen 0 region, yes, you'd
get two events -- the first would be 50x100+0+0, but the second would
be 100x100+0+0.

> I'd prefer not to introduce a change that requires clients to know how
> poorly the server is implemented.  Granted it wouldn't be the first
> semantic issue with Xinerama (check out how CopyArea from window to
> pixmap just plain doesn't emit GraphicsExpose), but why make it worse.

Yes, I agree that we have to maintain some semblance of conformance to
the specs; Xinerama is already enough of a disaster...

-- 
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/20131204/ce089f9c/attachment.pgp>