We removed the parameter from callers and from the implementation, but
not from the signature up top. I didn't notice because the branch I was
working on removed the signature entirely.
This code is only called with the current paint region as its argument.
Instead of having to copy it and do a no-op intersect against itself,
just use the current paint directly.
cairo_surface_create_for_rectangle takes a ref on the parent surface,
so we need to drop ours.
Rename get_window_surface to ref_window_surface to make the code more
clear and to stop this error from happening again.
Previously, each begin_paint_region added to a stack of current paints,
and when end_paint was called, the paint was popped off of the stack and
the surface was composited into the parent paint surface.
However, the code was broken in the case of a backend like Wayland which
didn't keep track of nested calls and simply wiped and returned the
native impl backing surface every time.
Since this feature is flat out unused by GTK+ and we don't want to
really support tricksy things like these for other clients, just remove
the feature. If somebody does call begin_paint_region more than once,
warn and return without doing anything.
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.
gtk_widget_set_double_buffered is now deprecated, and we don't support
non-double-buffered widgets. This means that under normal circumstances,
paints are never outside of a begin_paint / end_paint sequence, which
natively-double-buffered backends like Wayland can't possibly support.
When the pointer cursor is updated on CSW, lookup for either a device
cursor, or a global one. It would previously lookup for windows with
a global cursor, and then check if it had a device cursor, which would
skip windows with only device cursors set, and unexpectedly set the
global cursor.
This avoids a bunch of policy problems with deciding how to lay
out the window menu under different WMs.
For now, we use the special event _GTK_SHOW_WINDOW_MENU, but we
hope to have this standardized in wm-spec quite soon, as KDE wants
it as well.
Rendering doesn't do much about clipping drawing operations to the window shape,
although invalidation applies the shape to every window, leaving possibly trails
of "overrendered" content. So ensure the shape portions get invalidated too when
the window is moved/resized.
https://bugzilla.gnome.org/show_bug.cgi?id=729095
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.
The point of GdkWindowImpl::get_root_coords is to translate the passed
in coordinates against the passed-in impl window. For a child window,
in fact, window->abs_x and window->abs_y already track the child
window's coordinates against the impl window.
If we pass in a child window, and backends don't explicitly get the impl
window from it, we'll double-count the child window.
Really, we should *always* be passing impl windows to backends, and
never child windows. However, I'm a bit worried for regressions late
in the cycle if we want to fix up the rest of the callers, like
gdk_window_get_geometry, so I'm only going to touch get_root_coords
for now after careful review of all the backends.
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 EWMH defines _NET_WM_MOVERESIZE_SIZE_KEYBOARD and
_NET_WM_MOVERESIZE_MOVE_KEYBOARD for operations that are not
initiated by a button-press event. Allow using these by passing
a button of 0 to gdk_window_begin_move/resize_drag.
Since update_windows list is a static variable in GdkWindow.c which
contains pointers to windows which needs to be updated, it can happen
that it contains a pointer to a window even after quit from a gtk_main().
If another gtk_main() is called in the same process it tries to process
windows in the list which leads to a crash.
Correct reference count handling of added windows prevents such applications
from crash.
https://bugzilla.gnome.org/show_bug.cgi?id=711552
And deprecate the X11-specific version of it.
We call this new API _set_shadow_width() and not _set_frame_extents()
because we already have a gdk_window_get_frame_extents() with a
different meaning and different type of value.
https://bugzilla.gnome.org/show_bug.cgi?id=720374
If a motion event handler (or other handler running from the flush-events
phase of the frame clock) recursed the main loop then flushing wouldn't
complete until after the recursed main loop returned, and various aspects
of the state would get out of sync.
To fix this, change flushing of the event queue to simply mark events as
ready to flush, and let normal event delivery handle the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
Setting event compression to false will allow inter-frame
mouse motion events to be delivered, which are necessary
for painting applications to produce smooth strokes.
https://bugzilla.gnome.org/show_bug.cgi?id=702392
Discovered via a crash because b's (dest's) toplevel was NULL;
ensuring that the dest is actually a GdkWindow or setting b to NULL
prevents that path from being taken.
The version of device scale that landed in upstream cairo
master already inherits the device scale in cairo_create_similar,
so no need to do that in gtk anymore.
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.
If a cairo_surface for a window has a device scale set we need
to respect this when creating a similar window. I.e. we want
to then automatically create a larger window which inherits
the scale from the original.
We also need to calculate a different device_offset if there
is a device_scale set.
Only look at "impl" windows in gdk_window_process_updates_with_mode()
since these are the only ones we care about. This avoids a lot of
unnecessary calls to g_list_copy() and g_object_ref().
We don't want to recurse into children that are clipped, as that is
wasted work. We handle this by moving the empty check to the top
of the function and only using the clipped region everywhere.
We don't track the full clip for each window anymore, as this
is not useful when no windows are opaque. However, we still
need the full clip for the shape, so its calculated manually.
However, it was previously only recalculated when the clip changes
which doesn't correctly handle the case of a sibling geometry changing.
So, instead of doing this directly when geometry changes we just
set a bit in the toplevel whenever some window geometry changes, and
we then handle this in process_updates, updating the shape for all
native windows. This should be ok performance-wise because we don't
expect a lot of native children.
In the ancient X days you could have Xservers that had multiple active windows, like
one truecolor and one 8bit palette. Then most apps ran in 8bpp but a single window
would use truecolor. This is done by specifying different visuals for the windows.
To make this work we ensured that a window with a visual different from its parent
gets a native subwindow, so that X can tell the hardware to do its magic.
These days the only real time we get two different visual is when one is a rgba visual
and the other is not. So, the code to check this doesn't really do anything but
get in the way when someone accidentally manages to not get a rgba visual on
a child window (see bb7054b508). So, to avoid
such errors we just remove the "different visual than parent" check.
We need to send exposes for all native windows, even the ones
without an exposure mask set, because otherwise non-native
children of the native window with an exposure mask will
not be drawn.
This function returns all the children that has a specific user_data set.
This is used a lot in the new GtkWidget drawing code and doing
it this way is faster than getting every child and calling get_user_data
on each (which was a non-neglible part of the profiles). Additionally it
also allows use to use some kind of hashtable to make this operation even
faster if needed in the future.
This lets you register callbacks for when child widgets invalidate
areas of the window read it and/or change it.
For instance, this lets you do rendering effects and keeping offscreen
caches uptodate.
First of all, we now only do paints on native windows, as there is
really no reason anymore to do it for subwindows. Secondly, we
keep track of the paints even for GtkPaintable windows, but for
that case we don't create the offscreen surface, but rather
assume the windowing system does the backing store.
Now that all windows are non-opaque we can simplify the invalidation
a lot. There is no need to clip the invalidate area to child regions,
because we will always redraw everything under all the children.
We only have to handle native childen specially.
We now only do one expose event per native window, so there will
only be one begin/end_paint() call. This means all the work with
implicit paints to combine the paints on a single double buffer
surface is unnecessary, so we can just delete it.
We now consider non-native windows non-opaque, which means any invalid
area in a subwindow will also be invalid all the way up to the nearest
native windows. We take advantage of this by ignoring all expose events
on non-native windows (which typically means just the toplevel) and instead
propagating down the draw() calls to children directly via
gtk_container_propagate_draw.
This is nice as it means we always draw widgets the same way, and it
will let us do some interesting ways in the future.
We also clean up the GtkWidget opacity handling as we can now always
rely on the draing happening via cairo.
We can't really just draw by walking down the widget hierarchy, as
this doesn't get the clipping right (so e.g. widgets doing cairo_paint
may draw outside the expected gdkwindow subarea) nor does it let
us paint window backgrounds.
So, we now do multiple draws for each widget, once for each GdkWindow,
although we still do it on the same base cairo_t that we get for the
toplevel native window. The difference is only the clipping, the rendering
order, and which other widgets we propagate into.
We also collect all the windows of a widget so we can expose them inside
the same opacity group if needed.
NOTE: This change neuters gtk_widget_set_double_buffered for
widgets without native windows. Its impossible to disable
the double buffering in this model.
Since we dropped the move region optimization there is really no need
to try carefully keep track of opaque non-overlapped regions, as we
don't use this information to trigger the optimization anymore.
So, by assuming that all windows are non-opaque we can vastly simplify
the clip region stuff. First of all, we don't need clip_region_with_children,
as each window will need to draw under all children anyway. Secondly, we
don't remove overlapping sibling areas from clip_region, as these are
all non-opaque anyway and we need to draw under them
Finally, we don't need to track the layered region anymore as its
essentially unused. The few times something like it is needed we can
compute it explicitly.
For the case of native children of widgets we may cause a repaint
under native windows that are guaranteed to be opaque, but these
will be clipped by the native child anyway.
This basically neuters gdk_window_move_region, gdk_window_scroll
and gdk_window_move_resize, in that they now never copy any bits but
just invalidate the source and destination regions. This is a performance
loss, but the hope is that the simplifications it later allows will let
us recover this performance loss (which mainly affects scrolling).
If gdk_window_flush_outstanding_moves() creates new update area
we handle this directly in the same draw to avoid flashing.
This mainly affects win32 as X11 does its exposes from moves async.
However, its important for win32 since ScrollDC seems to sometimes
invalidate (and not copy) unexected regions.
http://bugzilla.gnome.org/show_bug.cgi?674051
If a window is overlapped by a layered (i.e. partially transparent)
window then that region will not disappear from the native window clip
region. This lets us handle compositing multiple layers of windows.
For native subwindows this doesn't really work. For them we apply the
clip region as a shape to the native window which lets us have client
side windows overlapping the native window. However, with the addition
of the layered stuff the "overlapped-by-alpha-csw" part got broken, as
this area is not removed from the clip region of the native window.
We fix this by also removing the layered area when applying the shape.
This means alpha and alpha backgrounds don't work over native windows,
but there is not much to do about that.
https://bugzilla.gnome.org/show_bug.cgi?id=696370
Both of them started to make use of round(), a C99 function. So, include
fallback-c89.c to provide a fallback implementation for round() for
compilers that don't have round()
https://bugzilla.gnome.org/show_bug.cgi?id=694339
* 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()
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.
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.
Since events can be paused independently for each window during processing,
make _gdk_display_pause_events() count how many times it is called
and only unpause when unpause_events() is called the same number of
times.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
When we have pending motion events, instead of delivering them
directly, request the new FLUSH_EVENTS phase of the frame clock.
This allows us to compress repeated motion events sent to the
same window.
In the FLUSH_EVENTS phase, which occur at priority GDK_PRIORITY_EVENTS + 1,
we deliver any pending motion events then turn off event delivery
until the end of the next frame. Turning off event delivery means
that we'll reliably paint the compressed motion events even if more
have arrived.
Add a motion-compression test case which demonstrates behavior when
an application takes too long handle motion events. It is unusable
without this patch but behaves fine with the patch.
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
Instead of having gdk_frame_clock_request_frame() have
gdk_frame_clock_request_phase() where we can say what phase we need.
This allows us to know if we get a frame-request during layout whether
it's just a request for drawing from the layout, or whether another
layout phase is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Some backends do not have slave devices, which means last_slave may be
NULL. Use the current device as the source device if last_slave is NULL
when synthesizing a crossing event.
https://bugzilla.gnome.org/show_bug.cgi?id=692411
We now store the current opacity for all windows. For native windows
we just call into the native implementation whenever the opacity changes.
However, for non-native windows we implement opacity by pushing a
second implicit paint that "stacks" on the existing one, acting as
an opacity group while rendering the window and its children.
This works well in general, although any native child windows will of
course not be opaque. However, there is no way to implement
implicit paint flushing (i.e. draw the currently drawn double buffer
to the window in order to allow direct drawing to the window).
We can't flush in the stacked implicit paint case because there
is no way to get the right drawing behaviour when drawing directly
to the window. We *must* draw to the opacity group to get the right
behaviour.
We currently flush if:
* A widget disables double buffering
* You call move/resize/scroll a window and it has non-native children
during the expose handler
In case this happens we warn and flush the outermost group, so there may
be drawing errors.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
_gdk_display_device_grab_update does not support passing in NULL for the
source device. If we don't have a slave device (saved in the pointer info)
then do not try and use that NULL pointer for the source_device.
This bug appeared in the Wayland backend where we (currently) only have master
devices exposed and as such no slave device is ever saved.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=692411
and gdk_window_get_fullscreen_mode() API to allow
applications to specify if a fullscreen window should
span across all monitors in a multi-monitor setup or
remain on the current monitor where the window is
placed.
Fullscreen mode can be either GDK_FULLSCREEN_ON_ALL_MONITORS
or GDK_FULLSCREEN_ON_CURRENT_MONITOR.
https://bugzilla.gnome.org/show_bug.cgi?id=691856
There are cases where crossing events aren't generated by input devices themselves
but rather through programmatical means (windows being moved/hidden/destroyed while
the pointer is on top).
Those events come from X as sourceid=deviceid, and GDK does its deal at lessening
this by setting a meaningful source device on such events, although this caused
some confusion on the mechanism to block/synthesize touch crossing events that
could possibly cause bogus enter events on the new window below the pointer.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=691572
We no longer support modifying GdkWindow hierarchies during
expose events. This is not working anymore anyway as the
flush operation now does not push already rendered pixels
in the flushed window from the double buffer to the window.
https://bugzilla.gnome.org/show_bug.cgi?id=679144
Avoid copying back partially drawn double-buffer data
when flushing to avoid flicker. This means non double
buffered widgets must draw opaque pixels in its expose
handlers, and that you are not allowed to use direct
rendering (or modify GdkWindow pos/size/order) from
inside the expose handler of a double buffered widget.
See https://bugzilla.gnome.org/show_bug.cgi?id=679144 for more
details
The code was calling _gdk_window_ref_cairo_surface in a few places
where the intent was not to read/write to the surface, but just look
at its type (to e.g. create a similar surface). This is bad, as that
operation causes a flush which may cause unnecessary work and/or
flashing. Instead we just get the impl surface in these cases.
GtkRange was using GDK_POINTER_MOTION_MASK, and it was not
getting any emulated motion events, because we only translate
from GDK_BUTTON_MOTION_MASK to GDK_POINTER_MOTION_MASK, but not
the other way around, and emulated_mask only had
GDK_BUTTON_MOTION_MASK in it. Now we put GDK_POINTER_MOTION_MASK
in emulated_mask and successfully match for windows that
have GDK_POINTER_MOTION_MASK or any of the button motion masks
selected.
This fixes range sliders not following the finger and jumping
to the last position upon release.
Events of type GDK_SCROLL will be received if the client side window
event mask has either GDK_SCROLL_MASK or GDK_SMOOTH_SCROLL_MASK.
GDK_BUTTON_PRESS_MASK has been removed from type_masks[GDK_SCROLL]
as that bit is often set for other-than-scrolling purposes, and
yet have the window receive scroll events. In GTK+, this forces
non-smooth events bubbling, even if the widgets above want smooth
events, and legitimately set GDK_[SMOOTH_]SCROLL_MASK.
If a device provides both smooth and non-smooth events, the latter will be
flagged with _gdk_event_set_pointer_emulated() so the client side window
receives one or the other. If a device is only able to deliver non-smooth
events, those will be sent, so both direction/deltas may need to be handled.
get_event_window() just checked on GDK_TOUCH_MASK, including for emulated
pointer events, so at the very least those should also match evmasks with
no touch events whatsoever
If an active grab kicks in on a different window, _gdk_display_has_device_grab()
would still find the former implicit grab for the window below the pointer, thus
sending events to an unrelated place.
If a grab with GDK_TOUCH_MASK kicks in due to a touch sequence emulating pointer
events, don't mutate the sequence into emitting touch events right away.
Create the backing GdkTouchGrabInfo for touches even if the pointer
emulating touch sequence is already holding an implicit grab on a
window that didn't select for touch events.
the backing GdkTouchGrabInfo will be needed if the overriding device
grab finishes before the touch does in order to send events back to
the implicit grab window. Instead, wait until the touch is physically
finished before removing the matching GdkTouchGrabInfo
GDK will only receive touch events when dealing with a multitouch
device, so these must be transformed to pointer events if the
client-side window receiving the event doesn't listen to touch
events, and the touch sequence the event is from does emulate
the pointer.
If a sequence emulates pointer events, it will result in a
button-press, N motions with GDK_BUTTON1_MASK set and a
button-release event, and it will deliver crossing events
as specified by the current device grab.
These are equivalent to an implicit grab (with !owner_events), so
if the touch leaves or enters the grab window, the other window
won't receive the corresponding counter-event.
If the touch sequence happens on a window with GDK_TOUCH_MASK set,
a GdkTouchGrabInfo is created to back it up. Else a device grab is
only created if the sequence emulates the pointer.
If both a device and a touch grab are present on a window, the later
of them both is obeyed, Any grab on the device happening after a
touch grab generates grab-broken on all the windows an implicit
touch grab was going on.
