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
>From e7878c6f194de42de4e054176a9de6d64351bd63 Mon Sep 17 00:00:00 2001
From: "Owen W. Taylor" <otay...@fishsoup.net>
Date: Thu, 14 Feb 2013 14:51:33 -0500
Subject: [PATCH] Don't compress motion events for different devices
---
gdk/gdkevents.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/gdk/gdkevents.c b/gdk/gdkevents.c
index 8e05a8e..4a9d0b9 100644
--- a/gdk/gdkevents.c
+++ b/gdk/gdkevents.c
@@ -268,6 +268,7 @@ _gdk_event_queue_handle_motion_compression (GdkDisplay *display)
GList *tmp_list;
GList *pending_motions = NULL;
GdkWindow *pending_motion_window = NULL;
+ GdkDevice *pending_motion_device = NULL;
/* If the last N events in the event queue are motion notify
* events for the same window, drop all but the last */
@@ -288,7 +289,12 @@ _gdk_event_queue_handle_motion_compression (GdkDisplay *display)
pending_motion_window != event->event.motion.window)
break;
+ if (pending_motion_device != NULL &&
+ pending_motion_device != event->event.motion.device)
+ break;
+
pending_motion_window = event->event.motion.window;
+ pending_motion_device = event->event.motion.device;
pending_motions = tmp_list;
tmp_list = tmp_list->prev;
--
1.8.0.2
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
