AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-12-30 15:31:34 +00:00
Code Issues Projects Releases Wiki Activity
2831dbb110
gtk/gdk/gdkframeclock.h

109 lines
4.8 KiB
C
Raw Normal View History

Add GdkFrameClock Add an object GdkFrameClock that we associate with a GdkWindow. This tracks when the window needs to be repainted, and will also be used for other operations in the future like relayout and updating animations. Based on a patch from Havoc Pennington: https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00004.html https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 22:34:01 +00:00
/* GDK - The GIMP Drawing Kit
* Copyright (C) 1995-1997 Peter Mattis, Spencer Kimball and Josh MacDonald
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
Changed obsolete FSF portal addresses to web address Fixed https://bugzilla.gnome.org/show_bug.cgi?id=721530
2014-01-12 12:56:49 +00:00
* License along with this library; if not, see <http://www.gnu.org/licenses/>.
Add GdkFrameClock Add an object GdkFrameClock that we associate with a GdkWindow. This tracks when the window needs to be repainted, and will also be used for other operations in the future like relayout and updating animations. Based on a patch from Havoc Pennington: https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00004.html https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 22:34:01 +00:00
*/
/*
* Modified by the GTK+ Team and others 1997-2010. See the AUTHORS
* file for a list of people on the GTK+ Team. See the ChangeLog
* files for a list of changes. These files are distributed with
* GTK+ at ftp://ftp.gtk.org/pub/gtk/.
*/
Fix some oversights with header guards Pointed out in https://bugzilla.gnome.org/show_bug.cgi?id=741254
2014-12-09 00:31:56 +00:00
#ifndef __GDK_FRAME_CLOCK_H__
#define __GDK_FRAME_CLOCK_H__
Add GdkFrameClock Add an object GdkFrameClock that we associate with a GdkWindow. This tracks when the window needs to be repainted, and will also be used for other operations in the future like relayout and updating animations. Based on a patch from Havoc Pennington: https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00004.html https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 22:34:01 +00:00
#if !defined (__GDK_H_INSIDE__) && !defined (GDK_COMPILATION)
#error "Only <gdk/gdk.h> can be included directly."
#endif
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.
2013-02-12 20:47:38 +00:00
#include <gdk/gdkframetimings.h>
Add GdkFrameClock Add an object GdkFrameClock that we associate with a GdkWindow. This tracks when the window needs to be repainted, and will also be used for other operations in the future like relayout and updating animations. Based on a patch from Havoc Pennington: https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00004.html https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 22:34:01 +00:00
G_BEGIN_DECLS
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.
2013-02-12 20:02:21 +00:00
#define GDK_TYPE_FRAME_CLOCK (gdk_frame_clock_get_type ())
#define GDK_FRAME_CLOCK(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), GDK_TYPE_FRAME_CLOCK, GdkFrameClock))
#define GDK_FRAME_CLOCK_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), GDK_TYPE_FRAME_CLOCK, GdkFrameClockClass))
#define GDK_IS_FRAME_CLOCK(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), GDK_TYPE_FRAME_CLOCK))
#define GDK_IS_FRAME_CLOCK_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), GDK_TYPE_FRAME_CLOCK))
#define GDK_FRAME_CLOCK_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), GDK_TYPE_FRAME_CLOCK, GdkFrameClockClass))
Add an UPDATE phase and GdkFrameClockTarget, use for GtkStyleContext Switch GtkStyleContext to using GdkFrameClock. To do this, add a new UPDATE phase to GdkFrameClock. Add a GdkFrameClockTarget interface with a single set_clock() method, and use this to deal with the fact that GtkWidget only has a frame clock when realized. https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-09-26 19:44:30 +00:00
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.
2013-02-12 20:02:21 +00:00
typedef struct _GdkFrameClock GdkFrameClock;
typedef struct _GdkFrameClockPrivate GdkFrameClockPrivate;
typedef struct _GdkFrameClockClass GdkFrameClockClass;
Add GdkFrameClock Add an object GdkFrameClock that we associate with a GdkWindow. This tracks when the window needs to be repainted, and will also be used for other operations in the future like relayout and updating animations. Based on a patch from Havoc Pennington: https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00004.html https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 22:34:01 +00:00
GdkFrameClock: update documentation
2013-02-13 02:42:49 +00:00
/**
* GdkFrameClockPhase:
* @GDK_FRAME_CLOCK_PHASE_NONE: no phase
* @GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS: corresponds to GdkFrameClock::flush-events. Should not be handled by applications.
Small documentation fixes for frame synchronization Found by Benjamin Otte
2013-02-14 18:50:55 +00:00
* @GDK_FRAME_CLOCK_PHASE_BEFORE_PAINT: corresponds to GdkFrameClock::before-paint. Should not be handled by applications.
GdkFrameClock: update documentation
2013-02-13 02:42:49 +00:00
* @GDK_FRAME_CLOCK_PHASE_UPDATE: corresponds to GdkFrameClock::update.
* @GDK_FRAME_CLOCK_PHASE_LAYOUT: corresponds to GdkFrameClock::layout.
* @GDK_FRAME_CLOCK_PHASE_PAINT: corresponds to GdkFrameClock::paint.
* @GDK_FRAME_CLOCK_PHASE_RESUME_EVENTS: corresponds to GdkFrameClock::resume-events. Should not be handled by applications.
* @GDK_FRAME_CLOCK_PHASE_AFTER_PAINT: corresponds to GdkFrameClock::after-paint. Should not be handled by applications.
*
* #GdkFrameClockPhase is used to represent the different paint clock
Include GdkFrameClock in the docs Make GdkFrameClock and GdkFrameTimings show up in the docs. A couple of minor doc fixes are also included.
2013-02-25 09:38:28 +00:00
* phases that can be requested. The elements of the enumeration
docs: fix typo in type name
2014-01-20 21:57:51 +00:00
* correspond to the signals of #GdkFrameClock.
GdkFrameClock: update documentation
2013-02-13 02:42:49 +00:00
**/
GdkFrameClock: Make the phase explicit when requesting the frame Instead of having gdk_frame_clock_request_frame() have gdk_frame_clock_request_phase() where we can say what phase we need. This allows us to know if we get a frame-request during layout whether it's just a request for drawing from the layout, or whether another layout phase is needed. https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 23:38:40 +00:00
typedef enum {
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. https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-09-26 14:28:06 +00:00
GDK_FRAME_CLOCK_PHASE_NONE = 0,
GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS = 1 << 0,
GDK_FRAME_CLOCK_PHASE_BEFORE_PAINT = 1 << 1,
GDK_FRAME_CLOCK_PHASE_UPDATE = 1 << 2,
GDK_FRAME_CLOCK_PHASE_LAYOUT = 1 << 3,
GDK_FRAME_CLOCK_PHASE_PAINT = 1 << 4,
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. https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-07 15:42:45 +00:00
GDK_FRAME_CLOCK_PHASE_RESUME_EVENTS = 1 << 5,
GDK_FRAME_CLOCK_PHASE_AFTER_PAINT = 1 << 6
GdkFrameClock: Make the phase explicit when requesting the frame Instead of having gdk_frame_clock_request_frame() have gdk_frame_clock_request_phase() where we can say what phase we need. This allows us to know if we get a frame-request during layout whether it's just a request for drawing from the layout, or whether another layout phase is needed. https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 23:38:40 +00:00
} GdkFrameClockPhase;
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
Add GdkFrameClock Add an object GdkFrameClock that we associate with a GdkWindow. This tracks when the window needs to be repainted, and will also be used for other operations in the future like relayout and updating animations. Based on a patch from Havoc Pennington: https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00004.html https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 22:34:01 +00:00
GType gdk_frame_clock_get_type (void) G_GNUC_CONST;
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
gdk_frame_clock_get_frame_time(): use gint64 for time
2013-02-13 13:35:05 +00:00
gint64 gdk_frame_clock_get_frame_time (GdkFrameClock *frame_clock);
GdkFrameClock: Make the phase explicit when requesting the frame Instead of having gdk_frame_clock_request_frame() have gdk_frame_clock_request_phase() where we can say what phase we need. This allows us to know if we get a frame-request during layout whether it's just a request for drawing from the layout, or whether another layout phase is needed. https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 23:38:40 +00:00
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
GdkFrameClock: update documentation
2013-02-13 02:42:49 +00:00
void gdk_frame_clock_request_phase (GdkFrameClock *frame_clock,
GdkFrameClock: Make the phase explicit when requesting the frame Instead of having gdk_frame_clock_request_frame() have gdk_frame_clock_request_phase() where we can say what phase we need. This allows us to know if we get a frame-request during layout whether it's just a request for drawing from the layout, or whether another layout phase is needed. https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 23:38:40 +00:00
GdkFrameClockPhase phase);
GdkFrameClock: add freeze/thaw Add the ability to freeze a frame clock, which pauses its operation, then thaw it again later to resume. Initially this is used to implement freezing updates when we are waiting for ConfigureNotify in response to changing the size of a toplevel. We need a per-window clock for this to work properly, so add that for the X11 backend. https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 23:42:13 +00:00
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
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. https://bugzilla.gnome.org/show_bug.cgi?id=693934
2013-02-15 22:04:39 +00:00
void gdk_frame_clock_begin_updating (GdkFrameClock *frame_clock);
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
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. https://bugzilla.gnome.org/show_bug.cgi?id=693934
2013-02-15 22:04:39 +00:00
void gdk_frame_clock_end_updating (GdkFrameClock *frame_clock);
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.
2013-02-12 20:47:38 +00:00
/* Frame history */
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
GdkFrameClock: update documentation
2013-02-13 02:42:49 +00:00
gint64 gdk_frame_clock_get_frame_counter (GdkFrameClock *frame_clock);
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
GdkFrameClock: update documentation
2013-02-13 02:42:49 +00:00
gint64 gdk_frame_clock_get_history_start (GdkFrameClock *frame_clock);
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
GdkFrameClock: update documentation
2013-02-13 02:42:49 +00:00
GdkFrameTimings *gdk_frame_clock_get_timings (GdkFrameClock *frame_clock,
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.
2013-02-12 20:47:38 +00:00
gint64 frame_counter);
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.) https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-11-14 17:49:06 +00:00
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
GdkFrameClock: update documentation
2013-02-13 02:42:49 +00:00
GdkFrameTimings *gdk_frame_clock_get_current_timings (GdkFrameClock *frame_clock);
Add GdkFrameClock Add an object GdkFrameClock that we associate with a GdkWindow. This tracks when the window needs to be repainted, and will also be used for other operations in the future like relayout and updating animations. Based on a patch from Havoc Pennington: https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00004.html https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 22:34:01 +00:00
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
GdkFrameClock: update documentation
2013-02-13 02:42:49 +00:00
void gdk_frame_clock_get_refresh_info (GdkFrameClock *frame_clock,
Add gdk_frame_timings_get_predicted_presentation_time() 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. Helper functions: gdk_frame_clock_get_current_frame_timings() gdk_frame_clock_get_refresh_info() are added for operations that would otherwise be needed multiple times in different locations. https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-11-15 19:11:41 +00:00
gint64 base_time,
gint64 *refresh_interval_return,
gint64 *presentation_time_return);
Add GdkFrameClock Add an object GdkFrameClock that we associate with a GdkWindow. This tracks when the window needs to be repainted, and will also be used for other operations in the future like relayout and updating animations. Based on a patch from Havoc Pennington: https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00004.html https://bugzilla.gnome.org/show_bug.cgi?id=685460
2012-10-03 22:34:01 +00:00
G_END_DECLS
#endif /* __GDK_FRAME_CLOCK_H__ */
Reference in New Issue Copy Permalink