Adam Jackson <a...@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.pack...@intel.com
pgpDsnQRQqGrY.pgp
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
