So dialogs, pop-ups, etc. behave as expected when parent is in
full-screen.
Tiling is allowed for normal windows and splash screens and disallowed
for others.
Closes https://gitlab.gnome.org/GNOME/gtk/issues/1627
This is necessary to give back focus to the Broadway elements when
content is embedded in an IFrame.
Signed-off-by: Mickael Istria <mistria@redhat.com>
There're two issues in GdkQuartzView's NSTextInputClient implementation
causes this bug.
1. The -(NSRange)selectedRange should not return [NSNotFound, 0] if
there's no selection. The accented character window will not show
if returned NSRange's location is NSNotFound. Instead of that, the
NSRange's location should be the caret position in the text input
buffer.
2. The accented character window will invoke
-(void)insertText:replacementRange: with non-empty replacement
range, to replace non-accented character with accented character
after user select it from accented character window. This case is
not implemented in original code. Here I use another gobject data
to pass the information to input module and convert it into
'delete-surrounding' event.
Besides these, there's another bug cause gtk_im_context_filter_keypress()
return wrong value while user press and hold a key. When user press
and hold a key, the accented character window will consume the
repeating key down event. Is this case, gtk_im_context_filter_keypress()
should return TRUE, indicate the key press is filtered by input
method module. But it will return FALSE because
gtk_im_context_filter_keypress() assume that every key press event
will generate some text from input method module.
Fixes#1618
And notify the shell about it. This is done through the
gtk_shell1.notify_launch request added in gtk-shell v3. All the plumbing
on the way to the activated application is already in place to transfer
the startup ID, so the other side just has to reply with
gtk_surface1.request_focus.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/624
This uses the gtk_surface1.request_focus request added in gtk-shell v3,
the given startup ID may be used by the compositor in order to determine
when was the request started, and whether user input happened in between.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/624
This version has 2 new requests:
- gtk_shell1.notify_launch notifies the compositor that the requesting
client shall launch another application. The given ID is expected to
be unique.
- gtk_surface1.request_focus notifies the compositor that a surface
requests focus due to it being activated. The given ID is passed to
this process through undetermined means, if it corresponds with a
current startup ID and there was no user interaction in between the
surface will be focused, otherwise it will demand attention.
To avoid confusion, have the NMake Makefiles output the built introspection
files in the same location where the binaries are built for the project
files, according to the Visual Studio version, platform and configuration
where the build is carried out.
Also make generating the introspection NMake snippet portion more robust to
source additions and removals by checking on Makefile changes too.
If the size was constrained by the xdg_positioner mechanisms, we handle
the resize by resizing the popup window. What we shouldn't do is
hide/show the popup window so avoid that.
The cache key is just the name of the cursor, so if a previously added
cursor had e.g. scale == 1, if we ask for a new cursor with scale == 2,
we might still fetch the scale == 1 cursor from the cache. Avoid this by
making sure the scale of the cached one is correct.
If it isn't, load the cursor as normal, and update the cache entry with
the new properly scaled cursor.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1183
CGDisplayModeGetWidth returns 0 if mode is NULL; that happens if the
CGDisplay is offline or mirroring another monitor and it leads to a
divide-by-zero crash.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1565
Tools on the same physical item have the same serial number, so the eraser
and the pen part of a single pen share that serial number. With the current
lookup code, we'll always return whichever tool comes first into proximity.
Change the code to use the hw id in addition to the serial number, this way we
can differ between two tools.
Generic tools (Bamboo, built-in tablets) always have the same serial number
assigned by the wacom driver. This includes the touch tool when the wacom
driver handles the touch evdev node (common where users require the wacom
gestures to work).
When the first device is the touch device, a tool is created with that serial.
All future tools now return the touch tool on lookup since they all share the
same serial number. Worse, this happens *across* devices, so the pen
event node gets assigned the touch tool because they all have the same serial.
Since we don't actually care about the touch as a tool, let's skip any unknown
tool. This captures pads as well.
Any wacom device currently sets the tool type to UNKNOWN. The wacom driver has
a property that exports the tool type as one of stylus, eraser, cursor, pad or
touch. Only three of those are useful here but that's better than having all
of them as unknown.
* We don't output spaces anywhere in the code, unlike the doc suggested.
* CSS explicitly forbids whitespace between function names and lparens:
https://stackoverflow.com/questions/13877198
We need to call g_strdup() on the name that we pass in for notifying the
GDK_SETTING event so that when we do gdk_event_free() later we will not
get a crash (stack corruption) that results from attempting to g_free()
something that is not dynamically allocated.
and convertPointFromScreen:, making them handle all MacOS versions
so that all of the if-deffing happens in the function definitions.
This happens to fix issue 1518 because it turns out that contrary
to the annotation in the 10.14 nNSWindow.h, convertPointToScreen and
convertPointFromScreen originate in 10.14, not 10.12.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1518
G_GNUC_END_IGNORE_DEPRECATIONS terminates the if statement and does not
consider the following block to be part of the if. So that block was
always taken irregardless of the pattern.
Fixes#1280
We don't want to set ParentRelative when:
- the parent window is NULL
In that case we are unsure about the depth, so better err on the side
of caution and avoid a BadMatch by accepting ugly output.
- the cairo pattern is in an error status
This should never happen - unless you start up in OOM - but better
be safe than sorry.
Might help with the spurious crashes in #1280.
Fixes#1280, tray icons not drawing background. This is a magic pattern only
usable for gdk_window_set_background_pattern() that sets the underlying
X window's background to ParentRelative.
Handling more flags, handling them correctly, and emitting the requisite
signals.
Change screen layout to use CGGetActiveDisplayList instead of NSScreens,
eliminating the latency between updating screens and recomputing the
root window.
Moving the initialization of the GdkQuartzMonitors to GdkQuartzDisplay from
the now-obsolete GdkQuartzScreen. Use QuartzDisplayServices for
monitor enumeration and to populate the GdkMonitor properties. This is
better aligned with acting on the Quartz Services callbacks for monitor
changes and with Cairo which also uses CoreGraphics for drawing.
This makes apps use "Segoe UI 9" by default instead of whatever matches "Sans 10".
It also cleans up the code and uses some new pango API while at it.
This was previously disabled in 9e686d1fb5 because it led to a poor glyph coverage
on certain versions of Windows which don't default to "Segoe UI 9" (Chinese, Korean, ..)
because the font fallback list was missing in pango.
This is about to get fixed in https://gitlab.gnome.org/GNOME/pango/merge_requests/34
so enable it again when we detect a new enough pango version.
Enables hinting, antialiasing and set the subpixel orientation according to the
active clear type setting. This ensures that font rendering with the fontconfig backend
looks similar to the win32 backend, at least with the default system font.
GTK widgets expect the scroll deltas to be 1 or -1 and calculate a scroll value from that.
Multiplying the delta by the Windows scroll line setting (which defaults to 3) results
in a much larger delta and vastly different behaviour for running a GTK app on Windows
vs on Linux. For example text view and tree view scroll by 9 lines per scroll wheel tick
per default this way while on Linux it is around 3.
Remove the multiplication for now.
Under Wayland, we are currently directly using GSettings
for desktop settings. But in a sandbox, we may not have
access to dconf, so this may fail. Use the new settings
portal instead.
By returning a default surface. The situation where there's no
currentContext arises when GtkCSS is trying to determine the
layout sizes so no actual display is necessary.
Closes: #1411
According to the XEmbed specification, a window should be created
"elsewhere" and then reparented into the target parent window. Instead,
GTK+ creates the window directly in desired target parent window. This
allows some races to occur.
Another program that does not follow XEmbed is tabbed. XEmbed requires
an _XEMBED_INFO property on the to-be-embedded window, but tabbed does
not check for this property. Thus, as soon as GTK+ creates its window,
tabbed starts managing this window and now GTK+ setting up the window
races with tabbed starting to manage the window.
If tabbed is fast enough to map the window, GTK+ never sees a MapNotify
event, because it did not yet select StructureNotifyMask on its window.
This results in a black window inside of tabbed.
Note that this cannot really be fixed in tabbed, since XEmbed says that
the _XEMBED_INFO property must be already present when the window
appears. Thus, patching tabbed to wait for _XEMBED_INFO to appear is not
something that the spec requires/allows.
Instead, this commit changes GTK+ so that it directly sets the right
event mask when the window is created. This means that there is no more
race between tabbed mapping the window and GTK+ selecting
StructureNotifyMask.
Note that the proper fix would be to do as XEmbed requires: Create the
window elsewhere and then reparent it into the target window. However,
that would require a more invasive patch, so this commit only takes the
"easy approach" of fixing this one race. Hopefully, all the other races
that can occur during window setup are harmless, because the
embedder/socket will hopefully watch for PropertyNotify events as
needed.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/757
See-also: https://github.com/awesomeWM/awesome/issues/2385
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead we just cache the monitor number and get
out of it the nsscreen when it is needed. This is
a requirement since it nsscreen it is not supposed
to be cached.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1312
Do not lie to W32 about the formats that we provide or accept.
Originally the logic behind such lies was that GdkPixbuf allows
us to convert any supported image to BMP or PNG, and therefore
we should announce that we always provide/accept BMP and PNG along
with other formats.
But that's not how it works. The conversion between formats happens
at GTK level in GtkClipboard or, if GtkClipboard is not used, with
gtk_target_list_add_image_targets() to announce all supported image
formats, and with gtk_selection_data_set_pixbuf() to convert from
any GdkPixbuf formats to the format requested by the selection, and
with gtk_selection_data_get_pixbuf() to convert from the selection
format to GdkPixbuf, if supported.
GDK simply does not play any role in this. Therefore W32 GDK backend
should only offer formats that it can actually do conversion for
by itself (such as image/bmp <-> CF_DIB,
or text/uri-list <-> CFSTR_SHELLIDLIST).
This leverages the normal input module switching mechanism in GTK
by making it think that the gtk-im-module setting changed.
The backend returns gtk-im-module value as "ime" if W32
IME API says that an IME is in use. Otherwise it returns
and empty string - this still triggers an input module
loading code, which, not being able to load the desired module
(which is and empty string), falls back to looking at current
keyboard layout.
Paired with the code that signals gtk-im-module change on keyboard layout
switches, this is sufficient to make GTK capable of loading appropriate
input modules at runtime. At least, the kinds of modules that specify
languages for which they are loaded automatically by default, and the
IME module.
Loading other kinds of input modules might still work via specifying
the gtk-im-module setting in gtk ini file, but doing so will likely
make GTK incapable of loading the IME input module that is used
for Korean, Chinese and Japanese (and some other languages).
Until someone figures out a way to actually change gtk-im-module
setting on Windows at runtime with meaningful values, the behaviour
introduced by this commit seems like a sufficient workaround.
Suggested by Garnacho. Hopefully fixes#1349.
Note: I'm riskily committing this via web UI not because I'm lazy
(though I am :) but because I'm seeing a weird host key when I try to
push or pull from GitLab.
Commit 359df028be changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT).
Windows defines deltas inversed for vertical direction
(positive values mean the wheel was turned forward)
but not for horizontal direction
(positive values mean the wheel was turned towards the right).
This commit fixes behavior as both axes were inverted previously.
Commit 359df028be changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT). Change it again, to send
both the GDK_SCROLL_SMOOTH and the GDK_SCROLL_(UP|DOWN|LEFT|RIGHT)
event separately (with the discrete event marked as emulated),
as this is what other backends (such as wayland) do.
For building the introspection dumper program on Visual Studio, leave out
the G_LOG_DOMAIN as g-ir-scanner does not like it when it constructs the
compiler command line for Visual Studio.
Also ensure that we are looking for the freshly-built libraries by looking
for the .lib's from the output directories of the Visual Studio project files.
Let's just use the fact that a window was mapped as a subsurface to
remap it above another transient parent instead of relying on the more
complicated 'should-map-as-subsurface' helper function.
Set delta_x or delta_y for GdkScrollEvent.
HIWORD (wParam) in WM_MOUSE(H)WHEEL is the scroll delta.
A delta value of WHEEL_DELTA (which is 120) means scrolling
one full unit of something (for example, a line).
The delta should also be multiplied by the value that the
SystemParametersInfo (SPI_GETWHEELSCROLL(LINES|CHARS), 0, &value, 0)
call gives back, unless it gives back 0xffffffff, in which case
it indicates that scrolling is page- or screen-based, not line-based
(GDK doesn't support that at the moment).
Also, all deltas should be inverted, since MS sends negative deltas
when scrolling down (rotating the wheel back, in the direction of
the user).
With deltas set the mode should be set to GDK_SCROLL_SMOOTH.
Fixes issue 1263.
gdk_win32_window_set_transient_for() behaves incorrectly when
called in sequence with the same arguments. This fix ensures it
always operates correctly.
In some cases this function gets called multiple times with the
same arguments, e.g. when tooltips are shown.
See issue #1214
The enum is duplicated in the spec for the manager and the decoration
object. We should be using the right ones. In practice they have the
same value, so this bug didn't cause any issues.
The wl_surface is destroyed and recreated when the window is
mapped/unmapped. As we have a new wl_surface we need to create a new
server_decoration object for that surface.
According to the spec compositors were to assume surfaces are CSD until
told otherwise. This means we need to send
org_kde_kwin_server_decoration_request_mode in both cases.
This fixes libreoffice under kwin, which would remove it's own headers
as per the manager's request but not inform kwin leaving it in the even
more broken state of having none.
Cursor surfaces didn't listen for output scale changes, meaning they
didn't adapt their scale when an output changed scale, which could
happen for example when changing the monitor scale via Settings.
We also need to invalidate the OpenGL/ES window when we resize the
window via a mouse drag operation, so that we don't get glitches in such
situations, because they are not covered in GdkWindow's
impl_class->move_resize().
Make sure that we only force the invalidation when necessary (as it is
expensive), and clean up the gdkevents-win32.c code so that we include
gdkglcontext-win32.h in the right place instead of using an extern, as
we need to invalidate the window accordingly.
We need to force redraws of the whole window when we are using EGL/ANGLE
during maximize, restore and Aerosnap ops so that we do not get glitches
in the resulting window.
This is for adding a EGL-based renderer which is done via the ANGLE
project, which translate EGL calls to Direct3D 9/11. This is done as a
possible solution to issue #105, especially for cases where the needed
full GL extensions to map OpenGL to Direc3D is unavailable or
unreliable, or when the OpenGL implementation from the graphics drivers
are problematic.
To enable this, do the following:
-Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are
available. A sufficiently-recent ANGLE is needed for things to
work correctly--note that the copy of ANGLE that is included in
qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause
license. Note also that Visual Studio 2013 or later is required to
build ANGLE from QT-5.10.1, but the 2013-built ANGLE DLLs can work
without without problems for GTK+ that is built with Visual Studio
2008 or later.
-Build libepoxy on Windows with EGL support enabled.
-Define GDK_WIN32_ENABLE_EGL when building gdk-win32.lib when building
with Visual Studio, or pass in --enable-win32-gles during configure
when building with MinGW/mingw-w64.
-Prior to running GTK+ programs, the GDK_GL envvar needs to contain
gles.
Known issues:
-Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed
extensions, notably GL_OES_vertex_array_object, but its ES 3 support is
sufficient.
-There is no autodetection or fallback mechanism to enable using
EGL/Angle automatically yet. There is no plans to do this in this
commit.
Thanks to LRN for pointing out that we should #include
"win32/gdkwin32.h" instead of #include "gdkwin32.h" for gdkgl.c. LRN
also did the autotools portion of this patch.
Further notes about the autotools --enable-win32-gles option, fom LRN:
This adds --enable-win32-gles option, which enables the
code for GLES renderer. This commit also adds tests for WGL and
EGL in epoxy. The absence of WGL is highly unlikely (it's enabled
by default), but checking for EGL when GLES is enabled is necessary,
as EGL is disabled in Windows builds of epoxy by default.
This functionality is similar to Linux's memfd. It creates anonymous shared memory without touching the filesystem, which allows it to work in Capsicum capability mode (sandbox).
In 01455399e8 ("gdk: do not deactivate surface on keyboard grabs"), we
made gdk avoid deactivating surfaces when another application takes a
keyboard grab, by using has_focus_window instead of has_focus. That however
broke activating surfaces when the gdk application acquired a grab itself,
in which case has_focus_window is false but has_focus is true.
We thus actually need to use both: surfaces should be activated either
because we have normal keyboard focus, or because we grabbed the keyboard.
This also renames HAS_FOCUS to APPEARS_FOCUSED to better reflect its
role.
Fixes#85
(cherry picked from commit 3287ac96e02ff236d74db10164c5b0c1e7b2b0bf)
There is no reason why we shouldn't pass this flag every time
Z-order changes. We have separate routines that are used to
maintain relative Z-order, so it should be completely OK to
pass SWP_NOOWNERZORDER to let the OS know that it shouldn't try
to maintain relative Z-order of the windows when raising them.
Pass SWP_NOOWNERZORDER when rising TEMP surfaces to the top. This ensures that
they don't drag anything else to the top with them. The use-case for this is
a tooltip (which must be on top) appearing for a non-foreground surface,
causing said surface to rise above other surfaces, some of which may
be foreground at the moment.
https://bugzilla.gnome.org/show_bug.cgi?id=784766
Fixes issue #852
Application is not expecting that.
Bug found due gdk_seat_grab() failure on Lock Screen. When user
Unlock the screen, the application is visible but does not receive
enter-event any more on X11/GNOME.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1485968
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1571422
Signed-off-by: Victor Toso <victortoso@redhat.com>
Signed-off-by: Carlos Garnacho <mrgarnacho@gmail.com>
This is the API used by GtkMenu to properly position menus on the screen
without requiring GTK to query the menu window's position or the work
area of where the window is positioned. It makes it possible to position
popup windows properly when using Wayland.
Make this API available to external users so custom popup windows can be
positioned properly as well.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/997
The 'gtk-fontconfig-timestamp' and 'gtk-modules' settings are
currently not available at all on Wayland. On X11, they are
implemented through xsettings maintained up-to-date by
gnome-settings-daemon.
This patch implements both GtkSettings for Wayland using a
new dbus interface also provided by gnome-settings-daemon.
Closes#886
gdk_wayland_*_grab()/ungrab() would emit crossing events which translate
as focus_in/focus_out events for keyboard.
However, the ungrab() functions compare the native toplevel as this is
what gets the Wayland pointer enter/leave events with the grab window,
so if the grab is issued on a child gdk window, those won't match and we
would emit more focus_out events than focus_in events.
This means that a widget such as spice-gtk which issues a keyboard grab
whenever the pointer enters the window and releases the grab when it
leaves the window would get uneven numbers of focus_in/focus_out events.
Also, gdk_wayland_seat_ungrab() would not emit crossing events for
keyboard devices, whereas gdk_wayland_device_ungrab() does, which adds
even more potential discrepancies between focus_in/focus_out events.
To solve this problem, introduce two new helper functions which check
the relevant native windows to emit crossing events when needed that get
called evenly from both gdk_wayland_seat_grab()/ungrab() and gdk_Wayland
_device_grab()/ungrab() APIs.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=780422
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/792
When an animated cursor was set and the previous cursor animation delay
happened to be the same, we wouldn't restart the animation timeout and
just return G_SOURCE_CONTINUE assuming the timer would continue. This
assumption is however only valid if the function was called from the
timeout, which is not the case.
Instead also arm the timer also if there is no previous timer active.
gdk_wayland_*_grab()/ungrab() would emit crossing events which translate
as focus_in/focus_out events for keyboard.
However, the ungrab() functions compare the native toplevel as this is
what gets the Wayland pointer enter/leave events with the grab window,
so if the grab is issued on a child gdk window, those won't match and we
would emit more focus_out events than focus_in events.
This means that a widget such as spice-gtk which issues a keyboard grab
whenever the pointer enters the window and releases the grab when it
leaves the window would get uneven numbers of focus_in/focus_out events.
Also, gdk_wayland_seat_ungrab() would not emit crossing events for
keyboard devices, whereas gdk_wayland_device_ungrab() does, which adds
even more potential discrepancies between focus_in/focus_out events.
To solve this problem, introduce two new helper functions which check
the relevant native windows to emit crossing events when needed that get
called evenly from both gdk_wayland_seat_grab()/ungrab() and gdk_Wayland
_device_grab()/ungrab() APIs.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=780422
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/792
The header linux/input.h used by GDK is specific to Linux. It is
possible to get a few Linux headers on FreeBSD by installing v4l_compat,
but it is usually better to use the one shipped with FreeBSD.
We prefer dev/evdev/input.h to linux/input.h here, so it will always use
dev/evdev/input.h on FreeBSD regardless of v4l_compat.
https://svnweb.freebsd.org/changeset/ports/465644
When pressing e.g. a window manager shortcut, which acquires keyboard grab,
Xorg would send FocusOut NotifyGrab then FocusIn NotifyUngrab. Currently
gdk would then deactivate the current surface, which makes accessibility
screen readers think that we have switched to a non-accessible application
and came back again, and thus reannounce the application frame etc. which we
don't want when e.g. just raising volume.
And actually, receiving FocusOut NotifyGrab does not mean losing the
X focus, it only means an application aqcuired a grab, i.e. it is
temporarily stealing keyboard events. On Wayland, this isn't even
notified actually.
This commit makes gdk only deactivate surfaces when there was an actual
focus switch to another window, as determined by has_focus_window (instead
of just has_focus), which happens either normally through FocusOut with
NotifyNormal, or during grabs through FocusOut with NotifyWhileGrabbed.
Fixes#85
(cherry picked from commit 01455399e8)
The shortcuts inhibitors hash table is created when we create a
GdkWaylandWindow implementation for a GdkWindow, and it's destroyed once
we finalize the instance. The fake "root" window we create for the
Wayland display does not have a backing native window, so the shortcuts
inhibitors hash table is set to NULL; this causes a critical error
message when calling g_hash_table_destroy() on it. The finalization of
the root window happens when we close a display connection.
We should use g_clear_pointer(), instead, as it's NULL safe.
Without this change, the displayclose test fails, as all warnings are
considered fatal.
Epoxy 1.4 has new ad hoc API that we can use to check whether GLX is
available on the current system.
If we didn't use this API, we'd have to manually dlopen libGL (or its
equivalent on different OSes) and check if it had GLX symbols; since
Epoxy already does all of this internally, we can simply ask it instead.
https://bugzilla.gnome.org/show_bug.cgi?id=775279
(cherry picked from commit 02eb344950)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
When asked for a nonexistent (positive) monitor number,
gdk_x11_display_get_monitor would (at best) return an uninitialized pointer,
instead of returning NULL.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/107
The stable xdg_shell port (5c8bb51a) introduced an error in
gdk_wayland_window_set_geometry_hints which would set the minimum size
to the maximum size, if provided.
This resulted in various wxWidgets apps (FileZilla, Audacity, Veracrypt)
crashing because they attempted to allocate a ginormous surface.
Fixes#157.
If a window is unmapped by the client while gdk is processing updates,
(for example Firefox un-mapping its window on Expose events), the
windowing backend resources might be lost (for example with Wayland)
which can cause a crash in end_paint().
Make sure we drop the cairo surfaces as well when hiding the surface,
that will avoid the crash in gdk_window_impl_wayland_end_paint() when
trying to attach the staging cairo surface to a released wl_surface,
these will be recreated when needed when the surface becomes visible
again and there is no need to keep such buffers around for a surface
which is not visible anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=793062
