Re: Answers to some comments about frame synchronization

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
instability. Its possible to temporarily raise this resolution by
timeBeginPeriod() although its frowned upon to always do this as it
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
switch g_get_monotonic_time() to using QueryPerformanceCounter() on
windows, and not worry about all the warnings you find on the
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
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
   the maximally consistent approach.

I'd say go with this.
I think the motion compression is still mishandling motion events
different devices, so that if you get two motion event streams for
same window from two devices they will be compressed together.

Ah, yeah, forgot about that. Do you think it needs anything more
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
worrying about compressing interleaved streams.

Nah, that seems fine.

Also, there seems to be no compression of touch events, which seems
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
motion where only painting programs actually care.

Yeah, lets skip this for now.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]