On Thu, 2013-02-14 at 13:52 -0500, Alexander Larsson wrote:
Some more feedback: Cut and paste doc bug: * @GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS: corresponds to GdkFrameClock::flush-events. Should not be handled by applications. * @GDK_FRAME_CLOCK_PHASE_BEFORE_PAINT: corresponds to GdkFrameClock::flush-events. Should not be handled by applications. The last one should be before-paint
Benjamin caught this too.
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 see that GtkTickCallback got a bool return value similar to GSource, which is bound to have the same kind of confusion wrt what value does what. Maybe we should have the G_SOURCE_REMOVE/CONTINUE equivalents already from the start to avoid this confusion.
Hmm, I didn't even know we added G_SOURCE_REMOVE / G_SOURCE_CONTINUE -
after 15 years it doesn't seem confusing to me!
The two possibilities here would be:
* Document people to use G_SOURCE_REMOVE / G_SOURCE_CONTINUE - this is
the maximally consistent approach.
* Add enum GtkTickCallbackReturn
{ G_TICK_CALLBACK_REMOVE, G_TICK_CALLBACK_CONTINUE }. This has the
advantage of compiler enforced type safety, but do we really want to
litter our code base with such two-element enums for every type of
callback?
If consistency with timeouts/idles wasn't an issue, I'm not sure I'd
have a return value at all - it's always possible to just remove.
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.
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. - Owen
Attachment:
0001-Don-t-compress-motion-events-for-different-devices.patch
Description: Text Data