Re: Answers to some comments about frame synchronization

[Alexander Larsson <alexl redhat com>]

> > Did you try this on win32? The default timer resolution there is
> > ~16msec which
> > is about the 60Hz frame rate, which seems like it can cause some
> > framerate
> > instability. Its possible to temporarily raise this resolution by
> > calling
> > timeBeginPeriod() although its frowned upon to always do this as it
> > raises
> > total system cpu use. Maybe we could hook this up to the default
> > paint clock,
> > so that whenever we're doing regular animations we increase the
> > timer resolution.
>
> I haven't tested on anything but X11. My feeling is that we should
> just
> switch g_get_monotonic_time() to using QueryPerformanceCounter() on
> windows, and not worry about all the warnings you find on the
> internet
> that on some old version of windows on some buggy bios that QPC jumps
> as you switch between cores.
>
> If it turns out that doesn't work, we can write some function that
> combines GetTickCount() and QPC and sanity-checks, interpolates, etc,
> but we really shouldn't do so without having demonstrated existence
> of
> such buggy systems among our user base.

I did a bunch of research on this, see the g_get_monitonic_time() win32
implementation for it. I definately don't think we can just rely on QPC
as is. Its not monotonic, it will drift over time and i believe over e.g.
cpu sleeps. If we use it we should slave it to the lower precision clock
in some kind of PLL (this is what firefox does). I just couldn't be
bothered with the complexity last time...

And anyway, the QPC time is just for reporting time. A poll() sleep (i.e.
MsgWaitForMultipleObjectsEx) will still use the timeGetTime precision, so
it does not help here.

> after 15 years it doesn't seem confusing to me!

We could just document that people should spend 15 years first!
 
> The two possibilities here would be:
>
>  * Document people to use G_SOURCE_REMOVE / G_SOURCE_CONTINUE - this
>  is
>    the maximally consistent approach.

I'd say go with this.
 
> > I think the motion compression is still mishandling motion events
> > from
> > different devices, so that if you get two motion event streams for
> > the
> > same window from two devices they will be compressed together.
>
> Ah, yeah, forgot about that. Do you think it needs anything more
> complex
> than the attached patch. I don't think getting continual streams of
> events for two devices is going to be common, so I'm not sure it's
> worth
> worrying about compressing interleaved streams.

Nah, that seems fine.

> > Also, there seems to be no compression of touch events, which seems
> > kinda
> > wrong, does it not?
>
> I think that should certainly wait until we have real usage of touch
> events to figure out. Emmanuele probably makes a good point that full
> history is probably more commonly useful for touch than it is for
> mouse
> motion where only painting programs actually care.

Yeah, lets skip this for now.