> > 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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
