We try to step the frame clock in whole refresh_interval steps, but to
avoid drift and rounding issues we additionally try to converge it to
be synced to the physical vblank (actually the time we get the
frame-drawn message from the compositor, but these are tied together).
However, the convergence to vsync only really makes sense if the new
frame_time actually is tied to the vsync. It may very well be that
some other kind of event (say a network or mouse event) triggered
the redraw, and not a vsync presentation.
We used to assume that all frames that are close in time (< 4 frames
apart) were regular and thus tied to the vsync, but there is really no
guarantee of that. Even non regular times could be rapid.
This commit changes the code to only do the convergence-to-real-time
if the cause of the clock cycle was a thaw (i.e. last frame drawn and
animating). Paint cycles for any other kind of reason are always
scheduled an integer number of frames after the last cycle that was
caused by a thaw.
When we get to a paint cycle we now know if this was caused by a
thaw, which typically means last frame was drawn, or some other event.
In the first case the time of the cycle is tied to the vblank in some
sense, and in the others it is essentially random. We can use this
information to compute better frame times. (Will be done in later
commits.)
The included fribidi header is not used in gdkkeys-wayland.c and already
included in gdk.c which causes linker issues due to the header defining
a global variable.
If you add a widget to a parent, this will invalidate the css nodes
for parent/siblings. Afterwards, if the parent is mapped, we will
realize the new child. This calls gtk_widget_update_alpha() which
needs the css opacity, so it revalidates the css.
Thus, for each widget_add (while visible) will trigger a full
revalidation of each sibling. If you add N children to a parent that
leads to O(N^2) revalidations.
To demo this I changed gtk-demo to always double the count
(independent of the fps) and print the time it took. Here is the
results (after a bit):
Setting fishbowl count=256 took 3,4 msec
Setting fishbowl count=512 took 10,1 msec
Setting fishbowl count=1024 took 34,1 msec
Setting fishbowl count=2048 took 126,3 msec
Setting fishbowl count=4096 took 480,3 msec
Setting fishbowl count=8192 took 1892,7 msec
Setting fishbowl count=16384 took 7751,0 msec
Setting fishbowl count=32768 took 38097,7 msec
Setting fishbowl count=65536 took 191987,7 msec
To fix this we drop gtk_widget_update_alpha() and just
calculate it when needed (which is only in a single place).
It was really only necessary because we previously set
the alpha on the surface.
With this fix the above becomes:
Setting fishbowl count=256 took 1,0 msec
Setting fishbowl count=512 took 1,9 msec
Setting fishbowl count=1024 took 3,7 msec
Setting fishbowl count=2048 took 7,4 msec
Setting fishbowl count=4096 took 18,1 msec
Setting fishbowl count=8192 took 31,0 msec
Setting fishbowl count=16384 took 66,3 msec
Setting fishbowl count=32768 took 126,7 msec
Setting fishbowl count=65536 took 244,6 msec
Setting fishbowl count=131072 took 492,2 msec
Setting fishbowl count=262144 took 984,3 msec
The new names are
GtkListView - listview row
GtkGridView - gridview child
GtkColumView - columnview header
columnview listview row
Adwaita css has been updated to preserve
existing styles.
Fixes: #2818
This was done in a weird way where we always call reftest_uninhibit_snapshot()
on paint, and then re-inhibited it if it wasn't inhibited. To make this
work it also started with an extra inhibit.
This is very contorted and based on how this historically worked. This
changes it to just do:
if (inhibit_count > 0)
return;
And keep inhibit_count at its initial zero value unless it is actually
inhibited.
In https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2027 i was getting
Bail out! ERROR:../testsuite/reftests/reftest-snapshot.c:212:reftest_uninhibit_snapshot: assertion failed: (inhibit_count > 0)
In (for example the box-shadow-changes-modify-clip reftest. I can reproduce this (on master) with:
```
$ xvfb-run -a -s "-screen 0 1024x768x24" meson test --suite gtk:reftest "reftest box-shadow-changes-modify-clip.ui"
...
1/1 gtk:reftest / reftest box-shadow-changes-modify-clip.ui ERROR 0.77s
``
Fix this by re-inhibiting if we didn't draw anything, or we will get an assert the next paint.
gtk_css_node_ensure_style() recurses over previous siblings to ensure
these have a style before its following sibling. As seen in
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2027 this can
cause us to stack overflow and crash if we have a lot of children.
And even if we don't have *that* many children its still somewhat
bad to have stack depths of the same magnitude as the number of
children, both for performance reasons and debuggability.
This is a demo that measures performance, so keep the child
info in a hashtable instead of a list. This means adding or removing
a child is not O(n-children).
Rename the show-separators property to show-row-separators,
and add a matching show-column-separators property. It is
implemented by setting the .column-separators style class
on the column view.
This is an expected feature with rubberband selection:
as you get close to the edge while doing rubberband
selection, the list scrolls to extend your selection.
Implement the typical rubberband selection, including
autoscroll. This is only useful with multiselection,
and not very compatible with single-click-activate.
Therefore, it is not enabled by default, and needs
to be turned on explicitly.
