Commit Graph

32 Commits

Author SHA1 Message Date
Matthias Clasen
61a51dea7b gdk: Dissolve gdk-autocleanup.h
Move the autocleanup declarations into their
respective headers.

While we are at it, correct the autocleanup
declaration for GdkEvent to use gdk_event_unref,
not g_object_unref. Oops
2022-09-23 19:49:58 -04:00
Christian Hergert
f5488bb4b2 gdk: fix typo in frame clock docs 2022-09-01 12:16:10 -07:00
Matthias Clasen
9132f1831c docs: Rework the gdk docs
Convert links, make things more concise.
2021-03-11 16:37:31 +00:00
Jonas Ådahl
4779e4e488 gdk/frame-clock: Remove the newly added 'compute-size' phase
What was previously done in the layout phase is now done in response to
a GdkSurface signal, which means size computation can happen on layout.
2020-12-07 09:46:39 +01:00
Jonas Ådahl
e07fde5c81 frame-clock: Add 'compute-size' phase
This will be handled between 'update' (which may trigger animation
ticks, CSS update, etc) and 'layout' which will allocate the widget
tree. It's meant to perform surface size computation, and is done
between these two phases in order to have an up to date state, and
letting the layout phase have an up to date size to layout in.
2020-12-07 09:46:39 +01:00
Matthias Clasen
b166999683 Add gdk_frame_clock_get_fps
We already have more than one copy of this code
in GTK, so just export this function.
2020-09-13 23:35:01 -04:00
Emmanuele Bassi
def700739d Use a single compilation symbol
We use a compilation symbol in our build to allow the inclusion of
specific headers while building GTK, to avoid the need to include only
the global header.

Each namespace has its own compilation symbol because we used to have
different libraries, and strict symbol visibility between libraries;
now that we have a single library, and we can use private symbols across
namespaces while building GTK, we should have a single compilation
symbol, and simplify the build rules.
2019-11-27 13:33:43 +00:00
Matthias Clasen
8755d884f3 Remove a lot of Since annotations
4.0 will represent a clean epoch. We don't want to have
lots of noise in the docs about 2.x or 3.x.
2018-06-25 19:55:04 -04:00
Matthias Clasen
4c150d8eb5 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-06 01:16:32 -05:00
Matthias Clasen
4f96353964 Fix some oversights with header guards
Pointed out in https://bugzilla.gnome.org/show_bug.cgi?id=741254
2014-12-08 19:31:56 -05:00
William Jon McCann
43bd9f210c docs: fix typo in type name 2014-01-20 18:27:28 -05:00
Andika Triwidada
0a768d274d Changed obsolete FSF portal addresses to web address
Fixed https://bugzilla.gnome.org/show_bug.cgi?id=721530
2014-01-12 19:56:49 +07:00
Matthias Clasen
ca81028901 Add GDK_AVAILABLE_IN_ALL annotations in gdk
This is in preparation to modernizing our handing
of exported symbols.
2013-05-05 15:38:46 -04:00
Matthias Clasen
67635e9177 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 10:54:32 +01:00
Cosimo Cecchi
7d4976b46e docs: add some missing gtk-doc blocks and Since tags for new API 2013-02-18 20:10:01 -05:00
Owen W. Taylor
1db87c897f 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-18 17:14:24 +01:00
Owen W. Taylor
6e986afbae Small documentation fixes for frame synchronization
Found by Benjamin Otte
2013-02-14 17:19:53 -05:00
Owen W. Taylor
4c9749ee9e gdk_frame_clock_get_frame_time(): use gint64 for time 2013-02-14 17:19:53 -05:00
Owen W. Taylor
815ef1bcc0 GdkFrameClock: update documentation 2013-02-14 17:19:53 -05:00
Owen W. Taylor
bb11195ec0 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()
2013-02-14 17:19:52 -05:00
Owen W. Taylor
515e5f74aa 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-14 17:19:52 -05:00
Owen W. Taylor
5f2d1654a5 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-14 17:19:52 -05:00
Owen W. Taylor
449e8c8856 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.
2013-02-14 17:19:52 -05:00
Owen W. Taylor
fb44ea8a85 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
2013-02-14 17:19:51 -05:00
Owen W. Taylor
15ee04c66f 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
2013-02-14 17:19:50 -05:00
Owen W. Taylor
3cef97f10d 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
2013-02-14 17:19:49 -05:00
Owen W. Taylor
a69285da08 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
2013-02-14 17:19:49 -05:00
Owen W. Taylor
344a69880a 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
2013-02-14 17:19:48 -05:00
Owen W. Taylor
1824796bfb 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
2013-02-14 17:19:48 -05:00
Owen W. Taylor
c4545cc5d4 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
2013-02-14 17:19:48 -05:00
Owen W. Taylor
7753883add Use GdkFrameClock for relayout
Add a ::layout signal to GdkFrameClock and use it instead of an idle
handler to drive the restyling and relayout of containers.

https://bugzilla.gnome.org/show_bug.cgi?id=685460
2013-02-14 17:19:47 -05:00
Owen W. Taylor
77bac0d6ae 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
2013-02-14 17:19:47 -05:00