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.
https://bugzilla.gnome.org/show_bug.cgi?id=693934
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.
We only draw the main entry on should_draw (widget->window), because
otherwise we also draw it on the GtkTextHandle widgets.
This is necessary due to the recent change for that to not return
TRUE and swallow the rest of the drawing operation.
This was causing warnings on widget unparent like:
Gdk-CRITICAL **: gdk_window_has_native: assertion `GDK_IS_WINDOW (window)' failed
Becasue the window was not properly removed from the lists on unrealize.
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.
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.
gtk_icon_info_copy and gtk_icon_info_free are deprecated for
the corresponding GObject methods.
We set correct transfer markup for the GtkIconInfo returning methods
to fix the introspection of them.
gtk_icon_info_load_symbolic_for_context_async had the wrong method
name in its documentation block.
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.
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.
* 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()
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.
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.
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.
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.
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.
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.
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.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
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.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
