Re: Answers to some comments about frame synchronization

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 
  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

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

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