There is really no need to store 128 doubles as axes,
ever. We can do just fine with 10. At the same time,
add a GdkAxisFlags member, so we can interpret the
values without having to go chasing the right device
for this information.
Only return one accumulated scroll event per frame.
Compress them by adding up the deltas.
Still missing: a way to capture history, like
we do for motion events.
Fixes: #2800
With the vendor provided Nvidia driver there is a small window of time
after drawing to a GL surface before the updates to that surface
can be used by the compositor.
Drawing is already coordinated with the compositor through the frame
synchronization protocol detailed here:
https://fishsoup.net/misc/wm-spec-synchronization.html
Unfortunately, at the moment, GdkX11Surface tells the compositor the
frame is ready immediately after drawing to the surface, not later,
when it's consumable by the compositor.
This commit defers announcing the frame as ready until it's consumable
by the compositor. It does this by listening for the X server to announce
damage events associated with the frame drawing. It tries to find the
right damage event by waiting until fence placed at buffer swap time
signals.
This commit moves some of the end frame sync counter handling
code to subroutines.
It's a minor readability win, but the main motivation is to
make it easier in a subsequent commit to defer updating the
sync counter until a more appropriate time.
commit 14bf58ec5d dropped support
for using the DAMAGE extension since there was no code that
needed it.
We're going to need it again, however, to address an NVidia
vendor driver issue.
This commit does the plumbing to add it back.
When the application does not receive "frame drawn" signals we schedule
the clock to run more or less at intervals equal to the last known
refresh interval. In order to minimize clock skew we have to aim for
exact intervals.
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.
Scroll events do not have a position, so they shouldn't implement the
GdkEventClass.get_position() virtual function; nor they should have an x
and y fields that never get updated.
When we run the frameclock RUN_FLUSH_IDLE idle before the paint,
then gdk_frame_clock_flush_idle() sets
```
priv->phase = GDK_FRAME_CLOCK_PHASE_BEFORE_PAINT
```
at the end if there is a paint comming.
But, before doing the paint cycle it may handle other X events, and
during that time the phase is set to BEFORE_PAINT. This means that the
current check on whether we're inside a paint is wrong:
```
if (priv->phase != GDK_FRAME_CLOCK_PHASE_NONE &&
priv->phase != GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS)
return priv->smoothed_frame_time_base;
```
This caused us to sometimes use this smoothed_frame_time_base even
though we previously reported a later value during PHASE_NONE, thus
being non-monotonic.
We can't just additionally check for the BEGIN_PAINT phase though,
becasue if we are in the paint loop actually doing that phase we
should use the time base. Instead we check for `!(BEFORE_PAINT &&
in_paint_idle)`.
We require a C compiler supporting C99 now. The main purpose of
these fallbacks was for MSVC. From what I can see this is now all supported
by MSVC 2015+ anyway.
The only other change this includes is to replace isnanf() with the
(type infering) C99 isnan() macro, because MSVC doesn't provide isnanf().
Without a way to create events, there is no point
in allowing gdk_display_put_event to be used from
the outside. And little good can come out of using
the other apis, so just make them all private.
A call to frame gdk_frame_clock_get_frame_time() outside of the paint
cycle could report an un-error-corrected frame time, and later a
corrected value could be earlier than the previously reported value.
We now always store the latest reported time so we can ensure
monotonicity.
In commit c6901a8b, the frame clock reported time was changed from
simply reporting the time we ran the frame clock cycle to reporting a
smoothed value that increased by the frame interval each time it was
called.
However, this change caused some problems, such as:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1415https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1416https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1482
I think a lot of this is caused by the fact that we just overwrote the
old frame time with the smoothed, monotonous timestamp, breaking
some things that relied on knowing the actual time something happened.
This is a new approach to doing the smoothing that is more explicit.
The "frame_time" we store is the actual time we ran the update cycle,
and then we separately compute and store the derived smoothed time and
its period, allowing us to easily return a smoothed time at any time
by rounding the time difference to an integer number of frames.
The initial frame_time can be somewhat arbitrary, as it depends on the
first cycle which is not driven by the frame clock. But follow-up
cycles are typically tied to the the compositor sending the drawn
signal. It may happen that the initial frame is exactly in the middle
between two frames where jitter causes us to randomly round in
different directions when rounding to nearest frame. To fix this we
additionally do a quadratic convergence towards the "real" time,
during presentation driven clock cycles (i.e. when the frame times are
small).
On my X11 + nvidia setup gnome-shell doesn't report presentation times.
However it does report refresh rate. We were mostly using this in our
calculation except when computing predicted presentation time, were
it fell back on the default 60Hz.
Don't call into the backends when the input region
or shadow width don't actually change. This avoid
distracting calls in debug logs, and just generally
is the right thing to do.
This is not used anymore now that surfaces are always toplevel in the
semantics of GdkWindow where child windows were available. We can drop
that and simplify the vfunc just a bit more.
Fixes#2765
On X11, shortcuts inhibition is emulated using a grab on the keyboard.
So if another widget ungrabs the keyboard behind our back (for example
when a popup window is dismissed) that effectively disables the effects
of the shortcut inhibition on the surface and we need to update the
shortcut inhibition status accordingly.
Check for "grab-broken" events on the surface and clear existing
shortcuts inhibition for the matching seat, so that the client can be
notified and may decide to re-enable shortcut inhibition if desired.
We pass the GdkEvent as a pointer, because the autogenerated marshallers
don't know how to handle GTypeInstance-derived classes.
Since the GValue box that we use in the marshaller passes the GdkEvent
instance as is, we also need to acquire a reference before invoking the
closure, and release it afterwards, to ensure that the GdkEvent instance
survices the invocation.
Just because we take a ref on a surface does not
guarantee that it is still usable a second later.
Check if its been destroyed in the meantime.
This is breaking the template tests in ci, since
there is no client behind the Broadway server.
The assumption is that the source device in events
is a slave device, so create pointer and keyboard
devices and use them in events.
This fixes the seat test on Broadway.
GDK backends are expected to keep a references on
their surfaces as long as they are associated with
external resources, and drop it in destroy().
This showed up as criticals in the shortcuts test
which manually creates and destroys surfaces.
If the tablet gets removed/freed while there are pad events in flight,
we leave a dangling pointer from the pad to the tablet, which may
lead to invalid reads/writes when handling the pad event(s).
If you run weston with the headless backend, you get a Wayland
display with no seat, which is just fine by the protocol.
gdk_display_get_default_seat() returns NULL in this case. Various
widgets assume that we always have a seat with a keyboard and a
pointer, since that is what X guarantees. Make things survive
without that, so we can run the testsuite under a headless
Wayland compositor.
In the gtk-demo drag-and-drop demo i can't drag anything, all I get
is:
(gtk4-demo:358993): Gdk-CRITICAL **: 09:36:19.617: Surface 0x7e1bb0 has not been mapped in GdkSeatGrabPrepareFunc
This is because GdkX11Drag.ipc_surface is not considered mapped, even
though we called gdk_x11_surface_show() on it, because the
GDK_SURFACE_STATE_WITHDRAWN flag is still set.
I added calls to gdk_synthesize_surface_state() to match what
e.g. show_popup() and gdk_x11_toplevel_present() does.
Tracking of those broke sometime along the gdk cleanups, so we
started missing some GDK_GRAB_BROKEN events from being emitted
(eg. after a button press/implicit grab triggers an active grab).
Implicit grabs are only added if there's no prior grab (either
implicit through other button presses, or explicit), in order to
keep accounting correct, make those prevail.
Conditionally check whether the Vulkan headers version defines
VK_RESULT_RANGE_SIZE, and avoid using it for version >=140. The
following comming in Vulkan-Headers has removed the enum value:
0c5351f5e9 (diff-4febd94c0666d59030d8b1dd20c72403)
