This is another step towards making GdkDisplayManager backend-agnostic.
Most of the backends profit from this as their atom implementations
where generic anyway - x11 needed that to allow multiple X displays and
broadway, quartz and wayland don't have the concept of displays.
The X11 backend still did things, so I only #if 0'd some code but did
not actually update anything.
On crossing events resulting from moving windows (eg. workspace switch),
deviceid equals sourceid, so make those reset scroll valuators on all
slave devices to avoid misleading jumps in scroll events
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=690275
The macros we had for checking for toplevel windows were passing
through the root window, which was not intentional and meant that
for the root window WINDOW_IS_TOPLEVEL() returned TRUE but
window->impl->toplevel was NULL, causing gdk_window_create_cairo_surface()
to crash.
* 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()
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.
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.
Instead of making the frame clock a settable property of a window, make
toplevel windows inherently have a frame clock when created (getting
rid of the default frame clock.) We need to create or destroy frame
clocks when reparenting a window to be a toplevel, or to not be a
toplevel, but otherwise the frame clock for a window is immutable.
If we get a focus event for a X window we don't recognize, just
ignore it and avoid a g-critical when
_gdk_device_manager_core_handle_focus() is called with a NULL window.
Deprecate gdk_window_enable_synchronized_configure() and
gdk_window_configure_done() and make them no-ops. Implement the
handling of _NET_WM_SYNC_REQUEST in terms of the frame cycle -
we know that all processing will be finished in the next frame
cycle after the ConfigureNotify is received.
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
We want the compositor to do different things for frames where
"slept before" is TRUE. Communicate to the compositor that
frame is a no-delay frame (slept_before=FALSE) by ending the frame
by increasing the counter value by 1, and that the frame is a
normal frame (slept_before=TRUE) by increasing the counter value
by 3.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
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
Instead of communicating the start of a frame to the window manager
as soon as we begin a frame, start a frame only when we know we've
actually created damage to the contents of a window.
(This uses cairo_set_mime_data() as a notification mechanism - a
clever suggestion from Uli Schlachter.)
The advantage of this is that we aren't forcing the compositor to
do a frame cycle and send _NET_WM_FRAME_DRAWN - depending on how the
compositor is structured that might either cause it to do extra
work or it might send _NET_WM_FRAME_DRAWN early and upset frame
timing.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Unqueuing events from the windowing system when paused could result
in weird reordering if event filters resulted in application-visible
behavior. Since we now resume events when the frame clock is frozen,
we now no longer count on low-level event handling running while
event handling is paused.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
By starting with an odd frame counter value, we make the mapping
and initial paint of the window an atomic operation, avoiding
any visual artifacts from an unpainted window.
Possible improvement: start the frame when doing gdk_window_show(),
so that the same improvement occurs for windows that were previously
shown and are being mapped again.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
When a window is unmapped, freeze its frame clock. This avoids doing
unnecessary work, but also means that we won't block waiting for
_NET_WM_FRAME_DRAWN messages that will never be received since the
frame ended while the window was withdrawn.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
As part of the extended _NET_WM_SYNC_REQUEST_COUNTER protocol,
we get a _NET_WM_FRAME_DRAWN message for each frame we draw. Use this
to synchronize the updates we are doing with the compositing manager's
drawing, and ultimately with with display refresh.
We now set the sync request counters on all windows, including
override-redirect windows, since it is also useful to do synchronized,
atomic updates for such windows.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
By exporting two XSync counters on a toplevel window, we subscribe
to an extended form of the _NET_WM_SYNC_REQUEST_COUNTER protocol,
where the window manager can initiate an atomic frame, as previously,
but the application can also do so by incrementing the new counter to
an odd value, and then to an even value to finish the frame.
See:
https://mail.gnome.org/archives/wm-spec-list/2011-October/msg00006.html
The support for 64-bit integers that GLib requires is used to
simplify the logic.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
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
We may receive events because SubstructureNotifyMask has been selected
for the root window. (Most likely, this would occur because GTK+
is being used inside a window manager like Metacity or Mutter.)
This can confuse various types of internal accounting, so detect
such events and comprehensively ignore them for GDK's internal
purposes. We still need to generate GDK events for these cases
because you can select for substructure events with
GDK_SUBSTRUCTURE_MASK.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Since XIQueryVersion, the bad API that it is, enforces the version from
the first client that requests it, for clients to be able to use the new
features in XI2.3, we need to ensure that we pass XIQueryVersion 2.3 as
the version that we support. We know that GTK+ won't be confused by the
new features.
https://bugzilla.gnome.org/show_bug.cgi?id=692467
The X server should fill in the minor version that it supports in the
case where it only supports the older version, so we can safely always
pass a higher version number than is potentially supported by the
server.
libXi was designed to be stable in the case where it doesn't recognize
requests or events/replies, so this should still work in a case where
we have new versions of the X server, and GTK+, but an old version of
libXi, at least for however well that setup should work.
https://bugzilla.gnome.org/show_bug.cgi?id=692467
Before acting on any hint that is set by the window manager we must
first check that the hint is supported by the current window manager.
Checking that a property has a value is insufficient as it may have
been set by a previous window manager which did support the hint.
https://bugzilla.gnome.org/show_bug.cgi?id=691515
This avoids a case where the display has been opened, but calling
gdk_display_get_default() in the callback doesn't work.
Reviewed-by: Benjamin Otte <otte@redhat.com>
By calling XSync in _gdk_x11_display_after_process_all_updates we
effectively make gdk rendering sync, which avoids problems with the
client animations running faster than the Xserver rendering, thus
filling up the X rendering pipes and essentially "locking up" the
Xserver (i.e. you can't even close the offending window because the
WM is starved too).
I verified this worked by making GtkSpinner paint multiple times on my
intel driver (which has some issue making this rendering slow atm),
and without this patch i get severe lag where even window dragging
stops for 5 seconds when i drag the mouse around. However, with the
patch everything is smooth.
https://bugzilla.gnome.org/show_bug.cgi?id=684639
After my recent fix for this, nautilus was still having problems
telling keeping F10 and Shift-F10 apart. With this change, we are
treating levels with the same symbol like inactive levels, ignoring
them entirely.
A change in xkeyboard-config 2.4.1 made it so that function keys
now have a shift level which has the same symbol, but 'eats' the
shift modifier. This would ordinarily make it impossible for us
to discriminate between these key combinations.
This commit tries harder to discriminate in 2 ways:
- XKB has a mechanism to tell us when a modifier should not be
consumed even though it was used in determining the level.
We now respect such 'preserved' modifiers. This does not fix
the Shift-F10 vs F10 problem yet, since xkeyboard-config does
not currently mark Shift as preserved for function keys.
- Don't consume modifiers that do not change the symbol. For
the function keys, the symbol on the shift level is the same
as the base level, so we don't consider Shift consumed.
For more background on the xkeyboard-config change, see
https://bugs.freedesktop.org/show_bug.cgi?id=45008https://bugzilla.gnome.org/show_bug.cgi?id=661973
This was showing up when using a combo box in list mode. After popping
up the list, the keyboard grab appeared stuck. What was stuck here is
only the client-side grab, since we forgot to clean up our grabs
when receiving an UnmapNotify.
This bug was introduced in 1c97003664.
GtkPlug directly handles X KeyPress/Release events, instead of using
translation in GDK (which expects XI2 events for XI2). When this
was done, the handling of the group was stubbed out and never replaced.
Export gdk_keymap_x11_group_for_state() and gdk_keymap_x11_is_modifier()
so we can fill out the fields correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=675167
Since the event will be ignored anyway after it's translated (slave
devices are disabled), don't let it run in the smooth scroll code path,
as it will burn our caches for the actual event we're interested in.
https://bugzilla.gnome.org/show_bug.cgi?id=673644
