The GLib main loop blocks on MsgWaitForMultipleObjectsEx to
determine if there are any incoming messages while also allowing
for background tasks to run. If all available messages are not
processed after MsgWaitForMultipleObjectsEx has signaled that
there are available, CPU usage will skyrocket.
From my limited understanding (by inspection of profiling
under Visual Studio):
Key is pressed - MsgWaitForMultipleObjectsEx unblocks, and
sends message to GDK's event handler. Some event is now queued.
g_poll unblocks, calls the g_event_dispatch which finally
resolves to gdk_event_dispatch. This then calls
_gdk_win32_display_queue_events, but since a message is already
queued, it fails to call PeekMessage and returns immediately.
At the next iteration, g_poll again calls MsgWaitForMultipleObjectsEx
which queues yet another event and returns almost immediately, since
there are events available which haven't been processed by PeekMessage.
The dispatch function is then called and the process repeats.
https://bugzilla.gnome.org/show_bug.cgi?id=771568
The main corpus of the documentation for gtk_window_get_size() is still
full of X11-isms, so we should port it to something that is more
backend-agnostic. Additionally, having some examples would be nice for
application authors looking at a way to appropriately use this function.
If somebody decides to use gtk_widget_set_double_buffered() in the
middle of a draw() then there's the risk of calling end_draw_frame()
with an invalid pointer.
Some overeager compilers may warn about the double_buffered bit field
changing values and leading to a potentially uninitialized variable.
In order to avoid compiler warnings or crashes, we can simply store the
value of the double_buffered bit field at the beginning of the rendering
and use that instead of the actual bit field.
https://bugzilla.gnome.org/show_bug.cgi?id=771463
Not all occurrences of this warning can be fixed today, so put it behind
a G_ENABLE_DEBUG flag since it still shows legitimate problems even if
some of them are false positives.
A popup may have moved and resized when configured. Make sure every
layer knows about this and call gdk_window_move_resize() with the
configured dimension and position. This won't actually move the
window, but might resize it.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
The result of move_to_rect, received from the xdg_popup.configure
event, needs to be translated to the correct coordinate space; that is
from real parent window geometry to coordinates relative to the gdk
window set as transient-for.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
Use a helper to translate a coordinate from non-real GdkWindow parent
to window geometry coordinate space of the real GdkWindow parent,
meaning the coordinate space of the GdkWindow of the parent used as a
xdg_popup parent where (0, 0) is inside of the shadow margin.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
When using the dynamic positioner (i.e. positioning from move_to_rect)
we can always rely on having a proper transient-for to position
relative to, so lets drop the ignored parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
Move the code used for calculating the result of move_to_rect
(final_rect, flipped_rect etc) closer to the other move_to_rect
functions (i.e. next to create_dynamic_positioner), and let the
xdg_popup configure handler just call the calculation function.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
If an application umaps the toplevel from its popup callback, this can
lead to a protocol error.
Make sure we mark popup parent and use that to check if their parent is
the toplevel being unmapped in which case we shall unmap the popup first
to avoid the protocol error.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=770906
The fix for bug 767468 had some unintended side-effects. This is
an attempt at doing the same fix (don't grab focus when we are
grab-shadowed), while avoiding the breakage, by using GTK+'s
internal tracking for grab-shadowed-ness.
https://bugzilla.gnome.org/show_bug.cgi?id=770508
