... and individually. It turns out that updating the opaque region
was causing the shape region to be updated, which was causing a new
shape mask to be generated and uploaded to the GPU. Considering
GTK+ regenerates the opaque region on pretty much any focus change,
this is not good.
At some point meta_window_actor_cull_out stopped calling
meta_cullable_cull_out_children which caused the unobscured region
to never be set for the stex.
https://bugzilla.gnome.org/show_bug.cgi?id=725216
For decorated windows, we don't want to apply any input
shape, because the frame is always rectangular and eats
all the input.
The real check is in meta-window-actor, where we consider
if we need to apply the bounding shape and the input shape
(or the intersection of the two) to the surface-actor,
but as an optimization we avoid querying the server in
meta-window.
Additionally, for undecorated windows, the "has input shape"
check is wrong if the window has a bounding shape but not an
input shape.
We need a MetaWaylandSurface to build a MetaSurfaceActor, but
we don't have one until we get the set_window_xid() call from
XWayland. On the other hand, plugins expect to see the window
actor right from when the window is created, so we need this
empty state.
Based on a patch by Jasper St. Pierre.
Turns out we only ever need to freeze/thaw whole windows, not
surfaces or subsurfaces.
This will allow removing the surface actor without losing
the count.
This time, to make way for MetaSurfaceActorEmpty. This also fixes
destroy effects as a side effect. It still has issues if we try
to re-assign an actor that's already toplevel (e.g. somebody
re-popping up a menu that's already being destroyed), but this
will be fixed soon.
The idea here is that MetaWindowActor will do the unparenting of
the surface actor when it itself is destroyed. To prevent bad issues
with picking, we only make the surface actor reactive when it's
toplevel.
We cannot intersect the the complete volume with the unobscured bounds
because it does not include the shadows. So just intersect it with the
windows's shape bounds and union it with the shadow bounds.
This also matches what the comment in the code says:
"We could compute an full clip region as we do for the window texture,
but the shadow is relatively cheap to draw, and a little more complex to clip,
so we just catch the case where the shadow is completely obscured
and doesn't need to be drawn at all."
The rendering logic before was somewhat complex. We had three independent
cases to take into account when doing rendering:
* X11 compositor. In this case, we're a traditional X11 compositor,
not a Wayland compositor. We use XCompositeNameWindowPixmap to get
the backing pixmap for the window, and deal with the COMPOSITE
extension messiness.
In this case, meta_is_wayland_compositor() is FALSE.
* Wayland clients. In this case, we're a Wayland compositor managing
Wayland surfaces. The rendering for this is fairly straightforward,
as Cogl handles most of the complexity with EGL and SHM buffers...
Wayland clients give us the input and opaque regions through
wl_surface.
In this case, meta_is_wayland_compositor() is TRUE and
priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND.
* XWayland clients. In this case, we're a Wayland compositor, like
above, and XWayland hands us Wayland surfaces. XWayland handles
the COMPOSITE extension messiness for us, and hands us a buffer
like any other Wayland client. We have to fetch the input and
opaque regions from the X11 window ourselves.
In this case, meta_is_wayland_compositor() is TRUE and
priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11.
We now split the rendering logic into two subclasses, which are:
* MetaSurfaceActorX11, which handles the X11 compositor case, in that
it uses XCompositeNameWindowPixmap to get the backing pixmap, and
deal with all the COMPOSITE extension messiness.
* MetaSurfaceActorWayland, which handles the Wayland compositor case
for both native Wayland clients and XWayland clients. XWayland handles
COMPOSITE for us, and handles pushing a surface over through the
xf86-video-wayland DDX.
Frame sync is still in MetaWindowActor, as it needs to work for both the
X11 compositor and XWayland client cases. When Wayland's video display
protocol lands, this will need to be significantly overhauled, as it would
have to work for any wl_surface, including subsurfaces, so we would need
surface-level discretion.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
It's mostly equivalent to the case where we've already detached
the pixmap, *except* for the x11_size_changed case. We can simply
detach the pixmap at the time the window changes size, though.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
We guarantee ourselves that a valid pixmap will appear any time
that the window is painted. The window actor will be scheduled
for a repaint if it's added / removed from the scene graph, like
during construction, if the size changes, or if we receive damage,
which are the existing use cases where this function is called.
So, I can't see any reason that we queue a redraw in here.
With the split into surface actors, we don't have an easy place
we can use to queue a redraw, and since it's unnecessary, we can
just drop it on the floor.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
We can never have a window actor that represents either the X root
window or the stage window, so it doesn't make sense to bail out
early in case we do.
I'd imagine that this came from a much earlier version of the code
where the compositor was much separate and had its own MapNotify
handling.
Since the unredirected window MetaWindowActor is stacked on top, it
will naturally get culled out of the process, so we can remove the
special casing here. Unfortunately, with the way that the code is
currently structured, it's too difficult to actually prevent setting
the clip / visible regions if the window is redirected, so just let
those be set for unredirected windows for now.
The input region was set on the shaped texture, but the shaped texture
was never picked properly, as it was never set to be reactive. Move the
pick implementation and reactivity to the MetaSurfaceActor, and update
the code everywhere else to expect a MetaSurfaceActor.
Traditionally, WMs unmap windows when minimizing them, and map them
when restoring them or wanting to show them for other reasons, like
upon creation.
However, as metacity morphed into mutter, we optionally chose to keep
windows mapped for the lifetime of the window under the user option
"live-window-previews", which makes the code keep windows mapped so it
can show window preview for minimized windows in other places, like
Alt-Tab and Expose.
I removed this preference two years ago mechanically, by removing all
the if statements, but never went through and cleaned up the code so
that windows are simply mapped for the lifetime of the window -- the
"architecture" of the old code that maps and unmaps on show/hide was
still there.
Remove this now.
The one case we still need to be careful of is shaded windows, in which
we do still unmap the client window. In the future, we might want to
show previews of shaded windows in the overview and Alt-Tab. In that
we'd also keep shaded windows mapped, and could remove all unmap logic,
but we'd need a more complex method of showing the shaded titlebar, such
as using a different actor.
At the same time, simplify the compositor interface by removing
meta_compositor_window_[un]mapped API, and instead adding/removing the
window on-demand.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
We want to remove a bunch of auxilliary duties from the MetaWindowActor
and MetaSurfaceActor, including some details of how culling is done.
Move the unobscured region culling code to the MetaShapedTexture, which
helps the actor become "more independent".
https://bugzilla.gnome.org/show_bug.cgi?id=720631
When we traversed down to reset the culling state, previously we
would just skip any actors that wanted culling. In order to properly
reset the unobscured_region before painting, we need to traverse down
to these places as well. Do this by calling cull_out with NULL regions
for both arguments, and adapt existing cull_out implementations to
match.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
I know it's confusing with the triple negative, but unredirected is how
we track it elsewhere: we have an 'unredirected' flag, and 'should_unredirect'.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
We currently ignore the unobscured region when we have mapped clones in
meta_window_actor_process_damage and meta_window_actor_damage_all but
use it unconditionally when computing the paint volume.
This is wrong. We should ignore it there as well or we will end up with
empty clones if the cloned window is completly obscured
(like the tray icons in gnome-shell).
https://bugzilla.gnome.org/show_bug.cgi?id=721596
We need to do this for XWayland windows, since we only get the event
telling us they're an XWayland window after the compositor knows about
the window.
I know it's confusing with the triple negative, but unredirected is how
we track it elsewhere: we have an 'unredirected' flag, and 'should_unredirect'.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
We no longer unmap the toplevel windows during normal operation. The
toplevel state is tied to the window's lifetime.
Call meta_compositor_add_window / meta_compositor_remove_window instead...
Traditionally, WMs unmap windows when minimizing them, and map them
when restoring them or wanting to show them for other reasons, like
upon creation.
However, as metacity morphed into mutter, we optionally chose to keep
windows mapped for the lifetime of the window under the user option
"live-window-previews", which makes the code keep windows mapped so it
can show window preview for minimized windows in other places, like
Alt-Tab and Expose.
I removed this preference two years ago mechanically, by removing all
the if statements, but never went through and cleaned up the code so
that windows are simply mapped for the lifetime of the window -- the
"architecture" of the old code that maps and unmaps on show/hide was
still there.
Remove this now.
The one case we still need to be careful of is shaded windows, in which
we do still unmap the client window. Theoretically, we might want to
show previews of shaded windows in the overview and Alt-Tab, so we remove
the complex unmap tracking for this later.
We need to set the number of components on the CoglTextureRectangle to
prevent wasting too much GPU memory. As we need to do this before we call
cogl_texture_set_region, just remove the meta_texture_rectangle_new wrapper,
and make callers call cogl_texture_rectangle_new_with_size directly.
The shadow is added in the paint step, not as a separate actor,
so the raise is a no-op. It also gets rid of an annoying misspelling
that's driving me crazy.
Since subsurfaces won't have toplevel MetaWindowActors, we need to
use MetaSurfaceActor instead. These are embedded in the MetaWindowActor,
just like MetaShapedTexture was (in fact, MetaSurfaceActor now contains
a MetaShapedTexture)
Make MetaWindowActor chain up to the generic default MetaCullable
implementation, and remove the helper methods for MetaSurfaceActor
and MetaShapedTexture.
Instead of hardcoded knowledge of certain classes in MetaWindowGroup,
create a generic interface that all actors can implement to get parts of
their regions culled out during redraw, without needing any special
knowledge of how to handle a specific actor.
The names now are a bit suspect. MetaBackgroundGroup is a simple
MetaCullable that knows how to cull children, and MetaWindowGroup is the
"toplevel" cullable that computes the initial two regions. A future
cleanup here could be to merge MetaWindowGroup / MetaBackgroundGroup so
that we only have a generic MetaSimpleCullable, and move the "toplevel"
cullability to be a MetaCullableToplevel.
https://bugzilla.gnome.org/show_bug.cgi?id=714706
For clarity, rename meta_window_get_outer_rect() to match terminology
we use elsewhere. The old function is left as a deprecated
compatibility wrapper.
When a Wayland compositor, simply rely on the clutter actor allocation
changed signal to sync geometry and emit window actor size changed
signals.
Attaching a wl_buffer to a MetaShapedTexture will signal allocation
changed on the corresponding MetaSurfaceActor, which the MetaWindowActor
is listening to.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=705502
Instead of having MetaWindowActor only have one single MetaShapedTexture
as actor drawing its content, introduce a new abstract MetaSurfaceActor
that takes care of drawing.
This is one step in the direction to decouple MetaWaylandSurface with a
MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order
to finally support subsurfaces like features, or any feature where
window is not drawn using a single texture.
The first step, implemented in this patch, is to not have
MetaWindowActor work directly with a shaped texture. There are still
some cases where it simply gets the texture and goes on as before, but
this should be changed by either removing the need of going via
MetaWindowActor or by adding some generic interface to MetaSurfaceActor
that doesn't limit its functionality to one shaped texture.
There should be no visible difference nor after this patch, but
meta_window_actor_get_texture() and meta_surface_actor_get_texture()
should be deprecated when equivalent functionality has been introduced.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=705502
The current time offset calculation is wrong. It is supposed to calculate
the offset between the current time and the
"time where it message should be sent" (last_time + interval).
Fix the math to actually do that.
https://bugzilla.gnome.org/show_bug.cgi?id=709340
We must set x11_size_changed even if we are frozen, as every window
size change makes the X server drop the pixmap, and we might lose
the information at the next thaw() if the window changes size
twice in one frame (so we would keep drawing with the old pixmap
until something else causes another resize)
We must send frame_drawn and frame_timing messages to even when
we don't actually queue a redraw on screen to comply with the
WM sync spec.
So throttle such apps to down to a ~100ms interval.
https://bugzilla.gnome.org/show_bug.cgi?id=703332
When we get a damage event we update the window by calling
meta_shaped_texture_update_area which queues a redraw on the actor.
We can avoid that for obscured regions by comparing the damage area to
our visible area.
This patch causes _NET_WM_FRAME_DRAWN messages to be not sent in some cases
where they should be sent; they will be added back in a later commit.
https://bugzilla.gnome.org/show_bug.cgi?id=703332
When drawing entirely opaque regions, we traditionally kept blending on
simply because it made the code more convenient and obvious to handle.
However, this can cause lots of performance issues on GPUs that aren't
too powerful, as they have to readback the buffer underneath.
Keep track of the opaque region set by windows (through _NET_WM_OPAQUE_REGION,
Wayland opaque_region hints, standard RGB32 frame masks or similar), and draw
those rectangles separately through a different path with blending turned off.
https://bugzilla.gnome.org/show_bug.cgi?id=707019
We need to use g_signal_connect_object(), rather than g_signal_connect(),
because the window actor can be destroyed before the window emits
the final notify::appears-focused inside unmanage, if the plugin
decides that it doesn't want to animate the destruction (which
happens with dialogs and the default plugin)
https://bugzilla.gnome.org/show_bug.cgi?id=706207
The previous code was leaving focus fields dirty in MetaWaylandPointer
and MetaWaylandKeyboard at time (which could crash the X server
because of invalid object IDs)
The new code is more tighly integrated in the normal X11 code
for handling keyboard focus (meaning that the core idea of input
focus is also correct now), so that meta_window_unmanage() can
do the right thing. As a side benefit, clicking on wayland clients
now unfocus X11 clients.
For the mouse focus, we need to clear the surface pointer when
the metawindowactor is destroyed (even if the actual actor is
kept alive for effects), so that a repick finds a different pointer
focus.
https://bugzilla.gnome.org/show_bug.cgi?id=705859
Remove window_surfaces, as the FIXME asks for. We don't need it
because we can obtain the surface from the MetaWindow, and
follow the wayland compositor path for both types of clients.
https://bugzilla.gnome.org/show_bug.cgi?id=705818
This copies the basic input support from the Clayland demo compositor.
It adds a basic wl_seat implementation which can convert Clutter mouse
events to Wayland events. For this to work all of the wayland surface
actors need to be made reactive.
The wayland keyboard input focus surface is updated whenever Mutter
sees a FocusIn event so that it will stay in synch with whatever
surface Mutter wants as the focus. Wayland surfaces don't get this
event so for now it will just give them focus whenever they are
clicked as a hack to test the code.
Authored-by: Neil Roberts <neil@linux.intel.com>
Authored-by: Giovanni Campagna <gcampagna@src.gnome.org>
This adds support for running mutter as a hybrid X and Wayland
compositor. It runs a headless XWayland server for X applications
that presents wayland surfaces back to mutter which mutter can then
composite.
This aims to not break Mutter's existing support for the traditional X
compositing model which means a single build of Mutter can be
distributed supporting the traditional model and the new Wayland based
compositing model.
TODO: although building with --disable-wayland has at least been tested,
I still haven't actually verified that running as a traditional
compositor isn't broken currently.
Note: At this point no input is supported
Note: multiple authors have contributed to this patch:
Authored-by: Robert Bragg <robert@linux.intel.com>
Authored-by: Neil Roberts <neil@linux.intel.com>
Authored-by: Rico Tzschichholz.
Authored-by: Giovanni Campagna <gcampagna@src.gnome.org>
We now track whether a window has an input shape specified via the X
Shape extension. Intersecting that with the bounding shape (as required
by the X Shape extension) we use the resulting rectangles to paint
window silhouettes when picking. As well as improving the correctness of
picking this should also be much more efficient because typically when
only picking solid rectangles then the need to actually render and issue
a read_pixels request can be optimized away and instead the picking is
done on the cpu.
This essentially just moves install_corners() from the compositor, through
the core, into the UI layer where it arguably should have been anyway,
leaving behind stub functions which call through the various layers. This
removes the compositor's special knowledge of how rounded corners work,
replacing it with "ask the UI for an alpha mask".
The computation of border widths and heights changes a bit, because the
width and height used in install_corners() are the
meta_window_get_outer_rect() (which includes the visible borders but not
the invisible ones), whereas the more readily-available rectangle is the
MetaFrame.rect (which includes both). Computing the same width and height
as meta_window_get_outer_rect() involves compensating for the invisible
borders, but the UI layer is the authority on those anyway, so it seems
clearer to have it do the calculations from scratch.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697758
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Send a _NET_WM_FRAME_DRAWN for each newly created window, as required
by the specification. This avoids a race where a window might be created
frozen but already unfrozen by the time we first see fetch the
counter value.
Remove a duplicate call to meta_compositor_set_updates_frozen() which
was called before the MetaWindowActor is created and hence did nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=694771
Now that the background actor is reactive, this means that
clicks on the window group part of the stage, even when they're
on an X window, will be registered as the background actor, as
all of the other children of the group aren't reactive. This can
happen when a plugin takes a modal grab, for instance.
https://bugzilla.gnome.org/show_bug.cgi?id=681540
We do, in fact, need freezing to affect window geometry, so that
move-resize operations (such as an interactive resize from the
left, or a resize of a popup centered by the application) occur
atomically.
So to make map effects work properly, only exclude the initial
placement of a window from freezing. (In the future, we may want
to consider whether pure moves of a window being done in response
to a user drag should also be excluded from freezing.)
Rename meta_window_sync_actor_position() to
meta_window_sync_actor_geometry() for clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=693922
If a window is frozen because it is repainting, that shouldn't kee[p
us from updating its position: we don't want a slow-to-update window
to move around the screen chunkily when dragged. (This does reduce
the efficiency of begin/end frames for replacing double-buffering,
but that never works very well in the case where there was an overlapping
window or the entire screen needed redrawing for whatever reason.)
This fixes a bug where a window that was mapped frozen would not get
positioned properly until after the map effect finished, and would
jump from 0,0 at that point. Since effects *do* need to prevent
actor repositioning by Mutter, we must position the actor before any
effect starts.
Because we now are queuing invalidates on frozen windows, fix the
logic for that so that we properly update everything when the window
unfreezes.
https://bugzilla.gnome.org/show_bug.cgi?id=693922
The WM spec requires _NET_WM_FRAME_DRAWN to *always* be sent when
there is an appropriate update to the sync counter value. We were
potentially missing _NET_WM_FRAME_DRAWN when an application did a
spontaneous update during an interactive resize and during effects.
Refactor the code to always send _NET_WM_FRAME_DRAWN, even when
a window is frozen.
https://bugzilla.gnome.org/show_bug.cgi?id=693833
Put override redirect windows such as menus into a separate window group
stacked above everything else. This will allow us to visually put these
above other compositior chrome.
Based on a patch from Muffin.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
When a client is drawing as hard as possible (without sleeping
between frames) we need to draw as soon possible, since sleeping
will decrease the effective frame rate shown to the user, and
can also result in the system never kicking out of power-saving
mode because it doesn't look fully utilized.
Use the amount the client increments the counter value by when
ending the frame to distinguish these cases:
- Increment by 1: a no-delay frame
- Increment by more than 1: a non-urgent frame, handle normally
https://bugzilla.gnome.org/show_bug.cgi?id=685463
We previously had timestamp information stubbed out in
_NET_WM_FRAME_DRAWN. Instead of this, add a high-resolution timestamp
in _NET_WM_FRAME_DRAWN then send a _NET_WM_FRAME_TIMINGS message
after when we have complete frame timing information, representing
the "presentation time" of the frame as an offset from the timestamp
in _NET_WM_FRAME_DRAWN.
To provide maximum space in the messages,_NET_WM_FRAME_DRAWN and
_NET_WM_FRAME_TIMINGS are not done as WM_PROTOCOLS messages but
have their own message types.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Instead of defining CLUTTER_ENABLE_EXPERIMENTAL_API and
COGL_ENABLE_EXPERIMENTAL_API in individual source files, enable
them on the command line. We weren't tracking exactly what pieces of
experimental API we were using and we were using the experimental
API in most source files that used Clutter and Cogl, so the
local #defines were annoying rather than useful.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
It's possible that a client might update the (extended)
_NET_WM_SYNC_REQUEST_COUNTER counter twice without actually drawing
anything. In that case, we still should send a _NET_WM_FRAME_DRAWN
message since it's hard for a client to know every case in which
no damage is generated. For now, do it the easy way by forcing a
stage repaint.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
When the application provides the extended second counter for
_NET_WM_SYNC_REQUEST, send a client message with completion
information after the next redraw after each counter update
by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Replace the unused meta_compositor_set_updates() with
a reversed-meaning meta_compositor_set_updates_frozen(), and use
it to implement freezing application window updates during
interactive resizing. This avoids drawing new areas of the window
with blank content before the application has a chance to repaint.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
This new hint allows compositors to know what portions of a window
will be obscured, as a region above them is opaque. For an RGB window,
possible to glean this information from the bounding shape region of
a client window, but not for an ARGB32 window. This new hint allows
clients that use ARGB32 windows to say which part of the window is
opaque, allowing this sort of optimization.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
With the shape region always set, it turns out the bounding region
is only used in one place, that's easily replaced with a variable
we already have available to us.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
With recent changes in the way the window mask texture is constructed,
the shape_region is always set, which means that we can remove
conditionals checking if the shape region is set.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
With the shape region always set, it turns out the bounding region
is only used in one place, that's easily replaced with a variable
we already have available to us.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
With recent changes in the way the window mask texture is constructed,
the shape_region is always set, which means that we can remove
conditionals checking if the shape region is set.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
Currently we only unredirect monitor sized override redirect windows.
This was supposed to catch fullscreen opengl games and improve
their performance.
Newer games like fullscreen webgl games and SDL2 using games (like L4D) as well as wine based games do not use override redirect windows so we need a better
heuristic to catch them.
GLX windows always damage the whole window when calling glxSwapBuffers and
never damage sub regions. So we can use that to detect them.
The new heuristic unredirects windows fullscreen windows that have damaged the
whole window more then 100 times in a row.
https://bugzilla.gnome.org/show_bug.cgi?id=683786
We should call meta_window_actor_detach not
meta_window_actor_queue_create_pixmap to create a new pixmap when we redirect a
previously unredirected window again.
https://bugzilla.gnome.org/show_bug.cgi?id=693042
With some recent changes to how mask textures are constructed from
shapes, a helper method we made was only called in one place, allowing
us to drop a reference/destroy, and remove a double clear.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
Due to a conditional error, meta_region_builder_add_rectangle was called
on every single blank pixel, rather than at the end of spans. With the new
rename, it's fairly clear to see the error. Fix the check to ensure that
we no longer make extraneous calls to meta_region_builder_add_rectangle.
https://bugzilla.gnome.org/show_bug.cgi?id=691874
There was a potential case where we were trying to use uninitialized memory,
in the case where the X server threw an error during XShapeGetRectangles.
In this case, we need to use the implicit shape for the window, which means
we need to rearrange code flow to make it work.
https://bugzilla.gnome.org/show_bug.cgi?id=677977
If a window has its BoundingRegion shaped, we shouldn't unredirect it,
as it expects the rest of the windows from being shown under it. This
prevents applications like the Skype screen recorder or gtkRecordMyDesktop
which want to show a "border" around the recorded area from being
unredirected, giving the appearance of making the desktop freeze.
https://bugzilla.gnome.org/show_bug.cgi?id=677657
This effectively makes MetaShapedTexture not a MetaShapedTexture, but a simple
and dumb MetaMaskedTexture, with an optimization for clipped regions.
We're doing this as the mask may need to be more complicated than made of
a cairo path -- we eventually want GTK+ to draw the entire frame background,
which we'll then scan.
https://bugzilla.gnome.org/show_bug.cgi?id=676052
As we want GTK+ to paint the mask on an A8, we can't simply use a cairo
path. A later commit will make this into a simple masked texture, and
meta-window-actor will be in control of the mask.
https://bugzilla.gnome.org/show_bug.cgi?id=676052
If we explicitly check for a NULL pointer, clang will assume
that the pointer may be NULL at some point. We clearly rely
on the pointer being non-NULL earlier, so fix this guy up.
https://bugzilla.gnome.org/show_bug.cgi?id=674876
