Commit Graph

51 Commits

Author SHA1 Message Date
Alexander Larsson
324202a56c profiler: Clean up profiler marks for frameclock
This drops the marks for before/after-paint as they are internal
things that very rarely use any time, and also flush/resume-events
as any events reported here will get separate marks so will be easy
to see anyway.

Also, we rename the entire frameclock cycle to "frameclock cycle"
rather than "paint_idle" which is rather cryptic.
2020-02-12 13:20:32 +01:00
Alexander Larsson
2890cd849f profiler: Add _end_mark() version of _add_mark()
These don't take a duration, instead they call g_get_monotonic_time() to
and subtract the start time for it.

Almost all our calls are like this, and this makes the callsites clearer
and avoids inlining the clock call into the call site.
2020-02-12 11:25:34 +01:00
Alexander Larsson
01d5ad2056 profiler: Make profiler-is-running a macro
When we use if (GDK_PROFILER_IS_RUNNING) this means we get an
inlined if (FALSE) when the compiler support is not compiled in, which
gets rid of all the related code completely.

We also expand to  G_UNLIKELY(gdk_profiler_is_running ()) in the supported
case which might cause somewhat better code generation.
2020-02-12 11:05:01 +01:00
Alexander Larsson
cc643df88b Convert all profiler times from nsec to usec
usec is the scale of the monotonic timer which is where we get almost
all the times from. The only actual source of nsec is the opengl
GPU time (but who knows what the actual resulution of that is).

Changing this to usec allows us to get rid of " * 1000" in a *lot* of
places all over the codebase, which are ugly and confusing.
2020-02-12 10:44:17 +01:00
Matthias Clasen
59a31e05bc gdk: Add a profiler mark for paint_idle
This is the big frame clock function where most
signals are emitted, and it can keep us away from
the mainloop for a long time.
2020-01-22 23:44:01 -05:00
Matthias Clasen
3c03d7970a More profiler reshuffling
Add more of the marks without requiring a debug build.
2020-01-22 23:44:01 -05:00
Matthias Clasen
56b8d1dfbe frame clock: Redo the profiler marks
Instead of reporting the frame clock phases as defined,
report the duration of the signal emissions, which is more
useful for tracking down what is taking time.
2020-01-22 16:36:02 -05:00
Matthias Clasen
7e59ec4afc Add clock freezes to the profile 2019-05-16 20:50:31 +00:00
Matthias Clasen
15fec034df always record a frame end time when profiling
We need to keep this time, or we may end up with
negative frame intervals.
2019-05-16 19:45:30 +00:00
Matthias Clasen
33ffd54d5f Redo frame profiling
We were adding incomplete frame timings to the
profile, which lead to occasional nonsense
numbers. Instead, only add timings to the profile
once we marked them as complete. This also
gives us an opportunity to add the presentation
time as a marker.
2019-05-16 19:08:34 +00:00
Matthias Clasen
ebc6bd834b profiling: Only use frame timings when we have them
Christian Hergert reported a crash here,
when testing the profiling code.
2019-05-14 12:06:55 +00:00
Matthias Clasen
1660bac6bd frame clock: Add tracing
Emit tracing data for frames. For now, we emit the
entire frame, and the layout and paint phases. Also
emit frames-per-second.
2019-05-07 09:37:59 -07:00
Benjamin Otte
0791924bf7 Convert fallthrough comments to G_GNUC_FALLTHROUGH
This way it's very obvious that fallthrough is indeed what we want.

Also bump the glib requirement to 2.59 which introduced
G_GNUC_FALLTHROUGH.
2019-04-15 14:40:25 +02:00
Chris Williams
0bf4c2420d gdkframeclockidle: Don't permanently skew frame time
Since commit 3b2f9395, the frame time may be set into the future, so
only ensure monotonicity, and don't store the offset. This prevents the
frame time from becoming out of sync with g_get_monotonic_time().

Fixes #1612
2019-04-09 16:26:25 -04:00
Chris Williams
f813bc1823 gdkframeclockidle: Remove unused struct member
compute_frame_time() has been using g_get_monotonic_time() instead of
GTimer since commit 7dfa4121.
2019-04-08 20:37:00 -04:00
Emmanuele Bassi
45361e19c3 Rename more GSources to use gtk 2019-02-06 10:37:24 +01:00
Benjamin Otte
50b8ee3a5f frameclockidle: Rename header so it's private now 2018-03-29 05:02:15 +02:00
Emmanuele Bassi
c655759cef Replace gdk_threads_add_timeout* with g_timeout_add()
The main GDK thread lock is not portable and deprecated.

The only reason why gdk_threads_add_timeout() and
gdk_threads_add_timeout_full() exist is to allow invoking a callback
with the GDK lock held, in case 3rd party libraries still use the
deprecated gdk_threads_enter()/gdk_threads_leave() API.

Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing timeout callbacks.

https://bugzilla.gnome.org/show_bug.cgi?id=793124
2018-02-03 12:06:58 +01:00
Daniel van Vugt
3b2f939590 Fix irregular gdk_frame_clock_get_frame_time
This fixes stuttering in animations that rely on the regularity of
gdk_frame_clock_get_frame_time.

https://bugzilla.gnome.org/show_bug.cgi?id=787665

BEFORE
gdkgears:
58 FPS and visibly stuttering
gnome-maps on a 59.95Hz monitor:
"paint" g_get_monotonic_time +17278μs, gdk_frame_clock_get_frame_time +17278μs
"paint" g_get_monotonic_time +17449μs, gdk_frame_clock_get_frame_time +17426μs
"paint" g_get_monotonic_time +17620μs, gdk_frame_clock_get_frame_time +17600μs

AFTER
gdkgears:
60 FPS and smoother
gnome-maps on a 59.95Hz monitor:
"paint" g_get_monotonic_time +18228μs, gdk_frame_clock_get_frame_time +16680μs
"paint" g_get_monotonic_time +15010μs, gdk_frame_clock_get_frame_time +16680μs
"paint" g_get_monotonic_time +17134μs, gdk_frame_clock_get_frame_time +16680μs
2017-12-09 20:52:36 -05:00
Benjamin Otte
43c212ac28 build: Enable -Wswitch-enum and -Wswitch-default
This patch makes that work using 1 of 2 options:

1. Add all missing enums to the switch statement
  or
2. Cast the switch argument to a uint to avoid having to do that (mostly
   for GdkEventType).

I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.

The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
2017-10-06 21:23:39 +02:00
Christian Hergert
b584b3d12a frame-clock: avoid g_signal_emit_by_name()
These were showing up higher in Sysprof profiles.

The simple fix is to avoid the emit_by_name() and let the interface emit
the signals directly. No function preconditions are provided since these
are internal API.
2016-04-18 15:33:53 -07:00
Matthias Clasen
ee217dc823 Add and use GDK_CHECK_DEBUG macro
This is following what we've already done in GTK+. It avoids
direct access to _gdk_debug_flags all over the place.
2016-02-28 21:40:30 -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
Bastien Nocera
438cd857c4 all: Add names to timeouts
Add names to every timeout we setup, so it's easier to track their
usage, and debug possible misbehaviour.

https://bugzilla.gnome.org/show_bug.cgi?id=710651
2013-10-23 13:31:18 +02:00
Jasper St. Pierre
c6de1cd6b9 gdkframeclockidle: Add explicit fallthrough markers
So people reading the code don't get confused.
2013-09-03 17:59:19 -04:00
Emmanuele Bassi
9f2ca8d851 gdk: Use new macros for defining private data
Drop the g_type_class_add_private() function, and use the macros
instead.

https://bugzilla.gnome.org/show_bug.cgi?id=702996
2013-07-09 09:28:49 +01:00
Alexander Larsson
c3bff30b50 gdkframeclock: Loop the layout phase if needed
In the case where the layout phase queued a layout we don't
want to progress to the paint phase with invalid allocations, so
we loop the layout. This shouldn't normally happen, but it may
happen in some edge cases like if user/wm resizes clash with
natural window size changes from a gtk widget. This should not
generally loop though, so we detect this after 4 cycles and
print a warning.

This was detected because of an issue in GtkWindow where it
seems to incorrectly handle the case of a user interactive resize.
It seems gtk_window_move_resize() believes that configure_request_size_changed
changed due to hitting some corner case so it calls
gtk_widget_queue_resize_no_redraw(), marking the window as need_alloc
after the layout phase. This commit fixes the issue, but we should
also look into if we can fix that.
2013-05-07 16:33:01 +02:00
Thomas Wood
e97262489c gdk: prevent NULL pointer access when debugging is enabled
If no updates, redraws, or repaints have been scheduled for this frame,
we will skip immediately to RESUME_EVENTS, and no GdkFrameTimings will
be created.

https://bugzilla.gnome.org/show_bug.cgi?id=694732
2013-02-26 15:27:53 +00:00
Matthias Clasen
82928c2a2a Pedantic fixes
Remove a C99 comment, and line up comment formatting.
2013-02-25 10:54:32 +01:00
Alexander Larsson
3c690c52ba Avoid loop in paint update cycle
Commit 1db87c897f accidentally removed
a check for !in_paint_idle in maybe_start_idle which causes us
to create a paint loop whenever something requests a phase
inside the paint_idle.
2013-02-19 21:12:48 +01:00
Alexander Larsson
5dbf814f0c 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.
2013-02-18 17:14:25 +01: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
d203f63641 GdkFrameClockIdle: remove timeouts in dispose
When a frame clock is disposed, remove active timeouts; also get
rid of the last traces of an unused GTimer.
2013-02-15 22:28:52 -05:00
Jasper St. Pierre
b777a16b06 gdkframeclockidle: Don't expose sleep_source source funcs 2013-02-15 19:48:56 -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
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
d5edf9c072 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.
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
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
8855bf052d Add GDK_DEBUG=frames
Add a debug option to print out detailed statistics about each frame drawn.

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

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

https://bugzilla.gnome.org/show_bug.cgi?id=685460
2013-02-14 17:19:50 -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
7dfa412188 GdkFrameClockIdle: add throttling to 60fps
If the backend is throttling paints, then the frame clock will be
frozen at the end of the frame. If not, then we need to add throttling,
so wait until 16ms after the start of the frame before beginning the
next frame.

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