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). -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg