[PATCH 02/13] randrproto: Panning protocol description

[Keith Packard]

On Thu, 2008-12-04 at 12:31 +0100, Matthias Hopf wrote:

> > I'd say all of this timestamp stuff can be eliminated.

What happens with timestamps is that an application queries the system,
then something unrelated changes, then the application tries to set some
parameters. The result is that the settings fail and if the application
has no recovery mechanism (which is likely), the user is left confused.
It's been a serious problem in the past, and the timestamps don't
eliminate inter-application races, they just narrow the window.

The random failures caused by timestamps have been far worse than any
race conditions we've found. If any thing "important" changes, the
request will fail anyway, due to match errors or resources disappearing.

> It turned out to be easier to understand, both in the spec and in code.
> Borders don't change if crtc dimensions change, while a separate box
> would.

Sorry, I just now realized that this rectangle can't be 'absolute' in
the same way the other rectangles can -- it moves with the panning
region. So, some alternative specification mechanism is required, either
the border values that you're using, or an offset rectangle which is
specified relative to the current CRTC origin.

I think using an offset rectangle would be less confusing than your
border regions, as there wouldn't be any ambiguity over whether positive
values were inside the crtc rectangle or outside. Having positive values
make the box smaller is counter-intuitive to me, but I wouldn't want the
'normal' values to be negative.

> I assume so. I guess they can be added later. Will do that, but will
> take some time.

I think we just need a picture of the four boxes here (screen, crtc,
border and tracking) so we can see how they nest or not).

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081204/821cbad0/attachment.pgp>