Traditionally, the way painting was done in GTK+ was with the
"expose-event" handler, where you'd use GDK methods to do drawing on
your surface. In GTK+ 2.24, we added cairo support with gdk_cairo_create,
so you could paint your graphics with cairo.
Since then, we've added client-side windows, double buffering, the paint
clock, and various other enhancements, and the modern way to do drawing
is to connect to the "draw" signal on GtkWidget, which hands you a
cairo_t. To do double-buffering, the cairo_t we hand you is actually on
a secret surface, not the actual backing store of the window, and when
the draw handler completes we blit it into the main backing store
atomically.
The code to do this is with the APIs gdk_window_begin_paint_region,
which creates the temporary surface, and gdk_window_end_paint which
blits it back into the backing store. GTK+'s implementation of the
"draw" signal uses these APIs.
We've always sort-of supported people calling gdk_cairo_create
"outside" of a begin_paint / end_paint like old times, but then you're
not getting the benefit of double-buffering, and it's harder for GDK to
optimize.
Additionally, newer backends like Mir and Wayland can't actually support
this model, since they're based on double-buffering and swapping buffers
at various points in time. If we hand you a random cairo_t, we have no
idea when is a good time to swap.
Remove support for this.
This is technically a GDK API break: a warning is added in cases where
gdk_cairo_create is called outside of a paint cycle, and the returned
surface is a dummy that won't ever be composited back onto the main
surface. Testing with complex applications like Ardour didn't produce
any warnings.
It seems that some backends implemented get_root_origin wrong
and returned the client window coordinates, not the frame window
coordinates. Since it's possible to implement generically for all
windows, let's do that instead of having a separate impl vfunc.
Instead of destroying the surface in the backend if this is
unable to resize, let the core code do it, and do it properly.
Based on a patch by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=725172
The broadway backend would move the focus from one window to another based on
where the mouse was (i.e. 'focus-follows-mouse' approach). Handling the focus
this wait didn't play well with widgets which rely on focus-in-event and
focus-out-event, like the GtkEntry when using a completion popup window, see
e.g:
https://bugzilla.gnome.org/show_bug.cgi?id=708984
So instead, setup broadway to require a click in a window to move the focus
(i.e. 'click-to-focus' approach):
* The implicit GDK_FOCUS_CHANGE events that were generated upon reception of
BROADWAY_EVENT_ENTER or BROADWAY_EVENT_LEAVE are removed.
* The broadway daemon will now keep track of which is the focused window
* Whenever the daemon detects an incoming BROADWAY_EVENT_BUTTON_PRESS, it will
trigger the focused window switch, which sends a new BROADWAY_EVENT_FOCUS to
the client, specifying which windows holds the focus.
* Upon reception of a BROADWAY_EVENT_FOCUS, the client will generate a new
GDK_FOCUS_CHANGE.
* gdk_broadway_window_focus() was also implemented, which now requests the
focus to the broadway server using a new BROADWAY_REQUEST_FOCUS_WINDOW.
This is based on an initial patch from Aleksander Morgado <aleksander@lanedo.com>.
We've long had double precision mouse coordinates on wayland (e.g.
when rotating a window) but with the new scaling we even have it on
X (and, its also in Xinput2), so convert all the internal mouse/device
position getters to use doubles and add new accessors for the
public APIs that take doubles instead of ints.
We now only update surface data after we have painted. Before we painted
in an idle, which meant we might send black data some times if we e.g.
resized the window and had not painted yet. Also, it means we're updating
less often to the daemon, saving resources.
We still have to queue a flush in the idle for non-draw operations,
otherwise e.g. resize of a toplevel will never be flushed if the clock
is frozen (e.g. during toplevel resize).
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.
With this we always roundtrip position change to the webbrowser.
This avoids conflicts when things change from both directions (app and user).
Also, we fake configure evens when there is no web client to ensure
apps get the events.
This (shouldn't) change any behaviour, but it moves the
webserver parts to a separate file, making the broadway display file
smaller and preparing for later separating out the server to its own
process.
When syncing windows, make sure we set transient-for before showing
the window to avoid it being visible with the wrong transient-for
(i.e. possibly on the wrong browser window).
Ensure that we're writing all the updates for a single rendering op
in one go without callbacks inbetween. That way some rendering will
be delayed, but the user will never see partial renderings.
