Cosimo Cecchi [Tue, 19 Feb 2013 00:14:13 +0000 (19:14 -0500)]
tests: workarounds to keep treeview scrolling tests running
We can't safely examine allocations synchronously using
gtk_main_iteration(), as there might be not enough time for a new paint
clock tick to have expired and the allocation set on the widget.
Work this around adding g_usleep() calls before processing pending
mainloop events.
Bastien Nocera [Mon, 18 Feb 2013 10:59:26 +0000 (11:59 +0100)]
GtkAccelLabel: Don't show "+" if there's no more keys to add
With the following code:
#define INVALID_CHAR GDK_KEY_VoidSymbol - 1
gtk_accelerator_get_label (INVALID_CHAR, GDK_SHIFT_MASK | GDK_CONTROL_MASK);
we would get this label:
Shift+Ctrl+
instead of this label:
Shift+Ctrl
win32: Request higher precision timers during animations
The default windows timer resolution is 16msec, which is too little
for fluent animations (say at 60Hz). So, while a paint clock is
active we temporarily raise the timer resolution to 1 msec.
Owen W. Taylor [Fri, 15 Feb 2013 22:04:39 +0000 (17:04 -0500)]
Add gdk_frame_clock_begin/end_updating()
Add an API to start or stop continually updating the frame clock.
This is a slight convenience for applcations and avoids the problem
of getting one more frame run after an animation stops, but the
primary motivation for this is because it looks like we might have
to use timeBeginPeriod()/timeEndPeriod() on Windows to get reasonably
accurate timing, and for that we'll need to know if there is an
animation running.
gdkwindown-win32.c included windows.h directly rather than via gdkwin32.h
which broke the build for me at least. Instead rely on it being included in
gdkwin32.h and things work right.
Owen W. Taylor [Sat, 16 Feb 2013 16:54:12 +0000 (11:54 -0500)]
GdkWindowX11: the root window is not a toplevel
The macros we had for checking for toplevel windows were passing
through the root window, which was not intentional and meant that
for the root window WINDOW_IS_TOPLEVEL() returned TRUE but
window->impl->toplevel was NULL, causing gdk_window_create_cairo_surface()
to crash.
Fix gtk_widget_add_tick_callback sometimes not working
We clear GtkTickCallbackInfo on creation to ensure all fields start
as 0. Before we sometimes ended up with destroyed being 1
so the tick was never called.
Owen W. Taylor [Thu, 14 Feb 2013 22:11:28 +0000 (17:11 -0500)]
GtkContainer: fix disconnection from frame clock
We need to disconnect the frame clock when we unrealize (at which
point the old clock is still alive) not in destroy(). Since there
is no common unrealize for containers, trigger this from GtkWidget.
Owen W. Taylor [Thu, 14 Feb 2013 19:51:33 +0000 (14:51 -0500)]
Don't compress motion events for different devices
A switch of device may be significant for an application, so don't
compress motion events if they are for different devices. This simple
handling isn't sufficient if we have competing event streams from
two different pointer events, but we don't expect this case to be
common.
Owen W. Taylor [Tue, 12 Feb 2013 20:03:21 +0000 (15:03 -0500)]
GdkFrameClock: Clean up the public API
* remove gdk_frame_clock_get_frame_time_val(); a convenience
function that would rarely be used.
* remove gdk_frame_clock_get_requested() and
::frame-requested signal; while we might want to eventually
be able to track the requested phases for a clock, we don't
have a current use case.
* Make gdk_frame_clock_freeze/thaw() private: they are only
used within GTK+ and have complex semantics.
* Remove gdk_frame_clock_get_last_complete(). Another convenience
function that I don't have a current use case for.
* Rename:
gdk_frame_clock_get_start() => gdk_frame_clock_get_history_start()
gdk_frame_clocK_get_current_frame_timings() => gdk_frame_clock_get_timings()
Owen W. Taylor [Tue, 12 Feb 2013 21:14:24 +0000 (16:14 -0500)]
GdkFrameTimings: strip down to a minimal public API
Since we're not exporting the ability to create your own frame
clock for now, remove the setters for GdkFrameTimings fields.
Also remove all setters and getters for fields that are more
about implementation than about quantities that are meaningful
to the applcation and just access the fields directly within
GDK.
Owen W. Taylor [Tue, 12 Feb 2013 20:47:38 +0000 (15:47 -0500)]
Merge GdkFrameHistory into GdkFrameClock
Now that GdkFrameClock is a class, not interface, there's no real advantage
to splitting the frame history into an aggregate object, so directly
merge it into GdkFrameClock.
Owen W. Taylor [Tue, 12 Feb 2013 20:02:21 +0000 (15:02 -0500)]
Change GdkFrameClock from an interface to a class
It's unlikely that anyone will want to have, say, a GtkWidget that
also acts as a GdkFrameClock, so an abstract base class is as
flexible as making GdkFrameClock an interface, but has advantages:
- If we decide to never make implementing your own frame clock
possible, we can remove the virtualization.
- We can put functionality like history into the base class.
- Avoids the oddity of a interface without a public interface
VTable, which may cause problems for language bindings.
Owen W. Taylor [Wed, 30 Jan 2013 20:09:44 +0000 (15:09 -0500)]
GdkWindow: make the frame clock an inherent property of the window
Instead of making the frame clock a settable property of a window, make
toplevel windows inherently have a frame clock when created (getting
rid of the default frame clock.) We need to create or destroy frame
clocks when reparenting a window to be a toplevel, or to not be a
toplevel, but otherwise the frame clock for a window is immutable.
Owen W. Taylor [Wed, 19 Dec 2012 17:03:16 +0000 (12:03 -0500)]
Add gtk_widget_add_tick_callback(), remove GtkTimeline, etc.
Add a very simple GtkWidget function for an "tick" callback, which
is connected to the ::update signal of GdkFrameClock.
Remove:
- GtkTimeline. The consensus is that it is too complex.
- GdkPaintClockTarget. In the rare cases where tick callbacks
aren't sufficient, it's possible to track the
paint clock with ::realize/::unrealize/::hierarchy-changed.
GtkTimeline is kept using ::update directly to allow using a GtkTimeline
with a paint clock but no widget.
Owen W. Taylor [Wed, 30 Jan 2013 20:11:59 +0000 (15:11 -0500)]
GdkX11DeviceManagerXI2: handle focus events not on a known window
If we get a focus event for a X window we don't recognize, just
ignore it and avoid a g-critical when
_gdk_device_manager_core_handle_focus() is called with a NULL window.
Deprecate gdk_window_enable_synchronized_configure() and
gdk_window_configure_done() and make them no-ops. Implement the
handling of _NET_WM_SYNC_REQUEST in terms of the frame cycle -
we know that all processing will be finished in the next frame
cycle after the ConfigureNotify is received.
Owen W. Taylor [Fri, 16 Nov 2012 15:47:17 +0000 (10:47 -0500)]
video-timer: add simple example of PLL-style clock adjustment
The first version of the video-timer simply played back the video
according to the wall clock, and showed each frame at the neareste
presentatin time. But an alternative strategy for playing back
video is that if the frame-rate is an integer-divisor of the
display refresh rate, or very close to that, is to change the playback
speed to complete avoid frame drops and changes in latency.
(This would require resampling audio if present.)
Demonstrate this technique by adding a --pll option to the
video-timer demo.
Owen W. Taylor [Thu, 15 Nov 2012 22:39:30 +0000 (17:39 -0500)]
video-timer: add a test case for display at a constant frame rate
Add a test case that simulates the timing operaton that goes on
when showing a constant frame rate stream like a video - each
frame is shown at the VBlank interval that is closest to when it
would ideally be timed.
For an operation like synchronizing audio to video playback, we need to
be able to predict the time that a frame will be presented. The details
of this depend on the windowing system, so make the backend predict
a presentation time for ::begin-frame and set it on the GdkFrameTimings.
The timing algorithm of GdkFrameClockIdle is adjusted to give predictable
presentation times for frames that are not throttled by the windowing
system.
Owen W. Taylor [Wed, 14 Nov 2012 22:54:03 +0000 (17:54 -0500)]
animated-resizing: enhance output
Show the average and standard deviation of the latency in addition to
the frame rate. Add options to print the output in machine-readable form,
and to control the frequency and total number of statistics that will be
output.
Owen W. Taylor [Wed, 14 Nov 2012 21:50:05 +0000 (16:50 -0500)]
GdkWindowX11: Communicate gdk_frame_timings_get_slept_before() to the compositor
We want the compositor to do different things for frames where
"slept before" is TRUE. Communicate to the compositor that
frame is a no-delay frame (slept_before=FALSE) by ending the frame
by increasing the counter value by 1, and that the frame is a
normal frame (slept_before=TRUE) by increasing the counter value
by 3.
Owen W. Taylor [Wed, 14 Nov 2012 21:08:08 +0000 (16:08 -0500)]
Add gdk_frame_timings_get/set_slept_before()
Add functions that tell us whether the main loop slept before we drew
a frame. Blocking with the frame clock frozen doesn't count as sleeping.
We'll use this to advertise to the compositor whether we
are drawing as fast as possible (and it should do the same) or timing
frames carefully (and it should do the same.)
Owen W. Taylor [Wed, 14 Nov 2012 18:26:13 +0000 (13:26 -0500)]
GdkFrameClockIdle: don't start the tiemout/idle when in a frame
Don't start the idle if we're in the middle of painting a frame -
this will prevent us from getting the timing right when starting
the idle after the frame.
Owen W. Taylor [Wed, 14 Nov 2012 17:49:06 +0000 (12:49 -0500)]
Add GdkFrameHistory and GdkFrameTimings, handle _NET_WM_FRAME_TIMINGS
In order to be able to track statistics about how well we are drawing,
and in order to be able to do sophisticated things with frame timing
like predicting per-frame latencies and synchronizing audio with video,
we need to be able to track exactly when previous frames were drawn
to the screen.
Information about each frame is stored in a new GdkFrameTimings object.
A new GdkFrameHistory object is added which keeps a queue of recent
GdkFrameTimings (this is added to avoid further complicating the
implementation of GdkFrameClock.)
Owen W. Taylor [Wed, 14 Nov 2012 17:23:41 +0000 (12:23 -0500)]
GdkWindowX11: Only start a frame when we emit damage
Instead of communicating the start of a frame to the window manager
as soon as we begin a frame, start a frame only when we know we've
actually created damage to the contents of a window.
(This uses cairo_set_mime_data() as a notification mechanism - a
clever suggestion from Uli Schlachter.)
The advantage of this is that we aren't forcing the compositor to
do a frame cycle and send _NET_WM_FRAME_DRAWN - depending on how the
compositor is structured that might either cause it to do extra
work or it might send _NET_WM_FRAME_DRAWN early and upset frame
timing.
Owen W. Taylor [Sun, 7 Oct 2012 18:13:56 +0000 (14:13 -0400)]
GdkDisplay: handle multiple calls to _gdk_display_pause_events()
Since events can be paused independently for each window during processing,
make _gdk_display_pause_events() count how many times it is called
and only unpause when unpause_events() is called the same number of
times.
Owen W. Taylor [Sun, 7 Oct 2012 15:47:49 +0000 (11:47 -0400)]
gdk_display_get_event: don't unqueue events from the windowing system when paused
Unqueuing events from the windowing system when paused could result
in weird reordering if event filters resulted in application-visible
behavior. Since we now resume events when the frame clock is frozen,
we now no longer count on low-level event handling running while
event handling is paused.
Owen W. Taylor [Sun, 7 Oct 2012 15:42:45 +0000 (11:42 -0400)]
GdkFrameClock: Reverse order of resume-events and afterpaint
Keeping events paused after the end of a frame put us in a
weird state where we had to process and queue events - so that
we would get the message from the compositor - but not deliver
them. Instead resume events before ending the frame.
Owen W. Taylor [Wed, 26 Sep 2012 14:28:06 +0000 (10:28 -0400)]
Compress motion synchronized with the paint cycle
When we have pending motion events, instead of delivering them
directly, request the new FLUSH_EVENTS phase of the frame clock.
This allows us to compress repeated motion events sent to the
same window.
In the FLUSH_EVENTS phase, which occur at priority GDK_PRIORITY_EVENTS + 1,
we deliver any pending motion events then turn off event delivery
until the end of the next frame. Turning off event delivery means
that we'll reliably paint the compressed motion events even if more
have arrived.
Add a motion-compression test case which demonstrates behavior when
an application takes too long handle motion events. It is unusable
without this patch but behaves fine with the patch.