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
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
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
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
_gdk_x11_moveresize_configure_done() isn't called for wmspec
moves/resizes so we don't have a way to notice when a wmspec
move/resize ends and consequently untrigger the sending of
_NET_WM_MOVERESIZE_CANCEL which results in this message always being
sent on the next button release event. In that case we are marking
that event as handled so it isn't processed further which breaks
button press/release event handling in several widgets.
To fix this we simply allow the normal event handling machinery to run
after sending the _NET_WM_MOVERESIZE_CANCEL message.
https://bugzilla.gnome.org/show_bug.cgi?id=673328
Since the order in which _NET_WM_STATE and _NET_WM_DESKTOP are set, or
even *if* they are set, isn't defined, we could end up unsetting
GDK_WINDOW_STATE_FOCUSED given that both handlers for these two X
properties end up doing window state changes for all states. As we
want GDK_WINDOW_STATE_FOCUSED to be set by default we need to set its
master flag by default as well.
https://bugzilla.gnome.org/show_bug.cgi?id=673125
If the Window Manager supports the _NET_WM_STATE_HIDDEN, we use it to use
the _NET_WM_STATE protocol when de-iconifying windows (iconification is
unchanged, via XIconifyWindow). Additionally, we no longer interpret all
UnmapNotify events for our window as the result of iconification.
(Based on patch by Tomas Frydrych <tf@linux.intel.com>)
This implements the following part of the EWMH spec:
"The special value _NET_WM_MOVERESIZE_CANCEL also allows clients to cancel the
operation by sending such message if they detect the release themselves
(clients should send it if they get the button release after sending the move
resize message, indicating that the WM did not get a grab in time to get the
release)."
In particular, it fixes the case of clicking widgets that use
gdk_window_begin_[resize|move]_drag*() and the click "sticking", i.e. the
mouse button getting released but the resize or move operation remaining in
effect.
https://bugzilla.gnome.org/show_bug.cgi?id=669208
The part in gdkwindow-x11.c which uses XIEvent and friends is "protected"
by HAVE_XGENERICEVENTS, i.e., XGetEventData() has been found. (Xlib.h)
XIEvent and friends are defined in <X11/extension/XInput2.h> which is
included by gdkdisplay-x11.h if XINPUT_2 is defined.
The patch makes sure XIEvent is only used if XINPUT_2 is defined.
https://bugzilla.gnome.org/show_bug.cgi?id=667534
When the X server does not support the shape extension (as some
vnc implementations seem to), our DND code was always seeing
an empty input shape, so drops always missed their target.
http://bugzilla.gnome.org/show_bug.cgi?id=620240
The current EWMH has added 'source indication' fields to a number
of client messages. Set these to 1 to indicate a regular client.
Also fill the button field of _NET_WM_MOVERESIZE.
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
Add a new window property which requests from the window manager
to hide titlebars when windows are maximized to account for this.
https://bugzilla.gnome.org/show_bug.cgi?id=665616
After consulting with Carlos, we agreed that it should be enough to grab
the core pointer instead of doing a full grab. If it turns out that's
wrong, we need to adapt the internal API for resizes to take the device
doing the resize.
Functions dealing with native Xlib types were (skip)ed because
gobject-introspection did not have correct Xlib types declarations.
They are corrected now, so these GdkX11 functions can be enabled back
again.
https://bugzilla.gnome.org/show_bug.cgi?id=655495
The metacity theme format allows to use colors from the current
GTK+ theme in window decorations. Since GTK+ now gained support
for dark theme variants, window managers using that theme format
(metacity, mutter, compiz via gtk-window-decorator) should be able
to use colors from the correct variant; so in case a variant is
requested, export it in the _GTK_THEME_VARIANT property on
toplevel windows.
https://bugzilla.gnome.org/show_bug.cgi?id=645354
The previous function gdk_drag_get_protocol_for_display() took native
window handles, so it had to be changed. Because it didn't do what it
was named to do (it didn't return a protocol even though it was named
get_protocol) and because it doesn't operate on the display anymore but
on the actual window, it's now called gdk_window_get_drag_protocol().
We need to defer setting the default display until the
GdkDisplay is fully initialized. Also, short-circuit some
encoding conversions when creating windows, to avoid an
implicit dependency on the display being in the list of
displays yet.
Move everything dealing with compound text to be X11 specific
Only gdk_text_property_to_utf8_list and gdk_utf8_to_string_target
are kept across backends, so add vfuncs for these.
Also, remove the non-multihead-safe variants of all these.
Moving the direct-access redefinitions of various macros
to gdkprivate-x11.h and use that header throughout in x11/.
Also remove a workaround for a long-fixed X server bug.
