When a window loses its frame we must unset any overlay path previously set on
the shaped texture.
Not doing so would cause rendering glitches near the window corners in
e.g. chrome/chromium by changing the Appearance preference "Use system title
bar and borders" → "Hide system title bar and use compact borders".
https://bugzilla.gnome.org/show_bug.cgi?id=659477
Our usage of DamageReportBoundingBox was causing us to miss some
updates when an area of the screen was drawn twice in rapid
succession. Add an explicit XSync() call to force the server
to flush rendering to the kernel before we draw.
https://bugzilla.gnome.org/show_bug.cgi?id=657071
Some apps that do a lot of rendering on the screen like games, mostly run in
fullscreen where there is no need for them to be redirected doing so does add
an overhead; while performance is critical for those apps.
This can be disabled / enabled at runtime using
meta_enable_unredirect_for_screen / meta_disable_unredirect_for_screen
https://bugzilla.gnome.org/show_bug.cgi?id=597014
The code here was wrong in every way: it only updated the shape if all the
borders changed. It never saved new last_borders even if it *had* changed,
and the bounding rectangle's x and y positions were still important otherwise.
This had user-visible impact when doing simple things like changing the
border_width. It would short-circuit here and due to the above incorrectness,
weirdness could happen where windows would be cut off and so on.
https://bugzilla.gnome.org/show_bug.cgi?id=656334
Since we're not setting the frame's output shape any more, it doesn't
make sense to calculate the output shape based on the frame window.
Instead, track the client window directly and calculate the output shape
based on that.
https://bugzilla.gnome.org/show_bug.cgi?id=644930
According to the XShape specification, the shaped region should always be
a subset of the bounding region. Certain programs such as wine depended
on this behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=627880
An ARGB window with a frame is likely something like a transparent
terminal. It looks awful (and breaks transparency) to draw a big
opaque black shadow under the window, so clip out the region under
the terminal from the shadow we draw.
Add meta_window_get_frame_bounds() to get a cairo region for the
outer bounds of the frame of a window, and modify the frame handling
code to notice changes to the frame shape and discard a cached
region. meta_frames_apply_shapes() is refactored so we can extract
meta_frames_get_frame_bounds() from it.
https://bugzilla.gnome.org/show_bug.cgi?id=635268
Using MetaWindowActor.opacity for _NET_WM_WINDOW_OPACITY makes it
difficult to implement effects like fading a window in on map.
Instead, set the opacity on the MetaShadedTexture child and use
it when drawing the shadow.
Since the check MetaWindowGroup does on meta_actor_get_paint_opacity()
no longer covers this, we need to handle the opacity in
meta_window_actor_get_obscured_region() explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=648613
We need to redraw a window's shadow any time the value of
meta_window_appears_focused() changes. So make that into a property so
we can get notifications on it.
https://bugzilla.gnome.org/show_bug.cgi?id=636904
Until the actor is destroyed, we need to have access to the
MetaWindow to access some fields used for painting. Keep a strong
reference to the window rather than just hoping the window will
not be freed.
https://bugzilla.gnome.org/show_bug.cgi?id=642787
If mutter is going to be a "real" library, then it should install its
includes so that users can do
#include <meta/display.h>
rather than
#include <display.h>
So rename the includedir accordingly, move src/include to src/meta,
and fix up all internal references.
There were a handful of header files in src/include that were not
installed; this appears to have been part of a plan to keep core/,
ui/, and compositor/ from looking at each others' private includes,
but that wasn't really working anyway. So move all non-installed
headers back into core/ or ui/.
https://bugzilla.gnome.org/show_bug.cgi?id=643959
Similar to the recently added 'size-changed' signal, we may want to do
something in response to a window being repositioned without waiting for
notify::allocation. (Especially since what we can do in notify::allocation
is severely limited by Clutter forbidding queueing an allocation at that
point.)
https://bugzilla.gnome.org/show_bug.cgi?id=641310
Emit a signal when the window size changes. While it is already
possible to connect to notify::allocation (or width/height), the
new signal is emitted outside a clutter allocation cycle, which
makes it more convenient when adjusting an actor's size/position
in response.
* GL_TEXTURE_RECTANGLE_ARB not avaliable
* clutter_glx_texture_pixmap_using_extension / CLUTTER_GLX_TEXTURE_PIXMAP not avaliable
Signed-off-by: Andreas Mueller <schnitzeltony@gmx.de>
Protect against shape_region or bounding_region being NULL in check_needs_shadow.
This can happen for short lived windows and result into a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=635421
This is just a microptimization, as we pretty much always use
TFP (and do the check every time we set a pixmap),
we can let gcc generate better code here.
https://bugzilla.gnome.org/show_bug.cgi?id=633002
Fullscreen and maximized windows never have visible shadows - the only
case where we would ever see them is if they bleed onto an adjacent
monitor and that looks bad.
It's small performance win to avoid computing them, and this also avoids
painting the top shadow for all maximized windows in GNOME Shell - since
the top panel isn't a X window, it doesn't factor into the computation
of what parts of windows are visible and maximized windows are computed
as having a top shadow.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
Instead of making optimizing obscured shadows an all-or-none operation,
pass the clip region to meta_shadow_paint() and only paint the 9-slices
that are at least partially visible.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
Instead of setting shadow parameters on individual windows, add the
idea of a "shadow class". Windows have default shadow classes based
on their frame and window type, which can be overriden by setting
the shadow-class property.
Each shadow class has separably configurable parameters for the
focused and unfocused state. New shadow classes can be defined with
arbitrary names.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
The basic MetaShadowFactory type is moved to a public header, while
the functions to fetch and paint shadows are kept private.
The public object will be used for configuration of shadows by
plugins.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
For attached modal dialogs, we want the shadow to fade out at the top
as if the window was glued to the parent at the top. Add a
shadow-top-fade property to MetaWindowActor and the corresponding
parameter to meta_shadow_factory_get_shadow().
The internal implementation of MetaShadow is adjusted to work
in terms of an "inner border" and "outer border" instead of doing
the calculations in terms of an aggregate border and the spread
of the shadow. The old way of doing things gets clumsy when the
top_fade distance is added in as well.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
The current shadow code just uses a single fixed texture (the Gaussian
blur of a rectangle with a fixed blur radius) for drawing all window
shadows. This patch adds the ability
* Implement efficient blurring of arbitrary regions by approximating
a Gaussian blur with multiple box blurs.
* Detect when multiple windows can use the same shadow texture by
converting their shape into a size-invariant MetaWindowShape.
* Add properties shadow-radius, shadow-x-offset, shadow-y-offset,
shadow-opacity to allow the shadow for a window to be configured.
* Add meta_window_actor_paint() and draw the shadow directly
from there rather than using a child actor.
* Remove TidyTextureFrame, which is no longer used
https://bugzilla.gnome.org/show_bug.cgi?id=592382
While the Meego developers agreed to switching mutter to GTK+-3.0
unconditionally a while ago, Canonical used a GTK+-2.0 build for their
Unity project. As Canonical now announced a switch to compiz as their
window manager, there is no longer a reason to maintain GTK+-2.0
compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=633133
Move all objects and functions namespaced with Mutter into the Meta namespace
to get a single consistent namespace. Changes that aren't simply changing mutter
to meta:
MutterWindow => MetaWindowActor
mutter_get_windows => meta_get_window_actors
mutter_plugin_get_windows => meta_plugin_get_window_actors
https://bugzilla.gnome.org/show_bug.cgi?id=628520
