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
Add a function to convert from g_get_monotonic_time() to a
"high-resolution server timestamp" with microsecond precision.
These timestamps will be used when communicating frame timing
information to the client.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Using a "sync delay" where we wait for 2 ms after the vblank before
starting to draw the next frame provides for much more predictable
latency for applications. An application can know that if it completes
a frame any time between 8ms before the vblank to the vblank,
it will reliably be drawn on the following vblank period, rather than
having an unpredictable latency depending on whether the compositor
is currently busy drawing a frame or not.
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
Some windows may already have event masks on them that we've selected
for, especially if we're using GTK+ windows. In particular, this fixes
window menus in the XI2 port.
https://bugzilla.gnome.org/show_bug.cgi?id=690581
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
In random places that are not grabs, we selected for events on
things like the root window, stage window, COW and more. Switch
these over to using the proper XI2 APIs.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
Currently keybindings are blocked while the compositor holds a grab; if
we want a keybinding to be available anyway, we use captured ClutterEvents
to determine the KeyBindingAction the event would have triggered and
run our own handlers (ugh).
Instead, provide a hook to allow the compositor to filter out keybindings
before processing them normally, regardless of whether the compositor
holds a grab or not.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
Using ClutterEffect is not pratical on MetaBackgroundActor, as the FBO
redirection has a noticeable performance impact. Instead, allow adding
GLSL code directly to the pipeline used to draw the background texture.
At the same time, port MetaBackgroundActor to modern Cogl API.
https://bugzilla.gnome.org/show_bug.cgi?id=669798
When support for multiple plugins was removed, the logic that was
supposed to send events to Clutter directly *only if there is no filter
function from a plugin* was broken, so events were being sent to
Clutter twice if Clutter didn't consume them the first time.
https://bugzilla.gnome.org/show_bug.cgi?id=686406
meta_window_group_paint tries to carefully figure out which parts of the
scene it can avoid painting. One area it avoids painting is the region of
the screen occupied by an unredirected window (if there's one present).
When subtracting from the visible region, it gets the coordinate spaces
confused, and ends up subtracting the area at the wrong offset. Fix this
by translating the rectangle subtracted from the visible region.
https://bugzilla.gnome.org/show_bug.cgi?id=677116
Instead of getting the x/y of the MetaBackgroundActor with respect to the
parent, use the same logic that we do for windows, fixing the case
where there is a more complex transformation involved.
https://bugzilla.gnome.org/show_bug.cgi?id=681221
Currently when the window group is moved, the visible region set
on the background actor no longer matches the actually visible
region, resulting in flickering around window actors.
Fix by translating the visible region with the window group.
https://bugzilla.gnome.org/show_bug.cgi?id=681221
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
The "multiple plugins loaded at once" strategy was always a big fiction:
while it may be viable if you're super careful, it's fragile and requires
a bit of infrastructure that we would be better off without.
Note that for simplicity, we're keeping the MetaPluginManager, but it only
manages one plugin. A possible future cleanup would be to remove it entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=676855
We already check that the plugin has the appropriate vfunc in the klass
structure, so we shouldn't need to check for the same data again with
a "features" long.
https://bugzilla.gnome.org/show_bug.cgi?id=676855
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
meta_window_actor_has_shadow() is called for every paint for every
window, verbosely logging in it makes the output of MUTTER_VERBOSE
pretty much useless.
All animations use the constants directly, so this is just declaring
a bunch of local variables and then doing nothing with it.
Another clang warning.
https://bugzilla.gnome.org/show_bug.cgi?id=674876
Cogl now has public experimental API to create a rectangle texture
which we can use instead of creating a foreign texture with GL. This
avoids Mutter depending on Cogl including a GL header from its public
headers which it might not do in future.
https://bugzilla.gnome.org/show_bug.cgi?id=672711
Since Cogl doesn't support multi-texturing with sliced textures and the
shape texture is combined with the texture-from-pixmap texture we need
to make sure we never construct a sliced mask texture. This patch simply
passes the COGL_TEXTURE_NO_SLICE flag to cogl_texture_from_data when
creating the shape mask texture.
https://bugzilla.gnome.org/show_bug.cgi?id=674731
A lot of code did something similar to:
MetaFrameBorders borders;
if (window->frame)
meta_frame_calc_borders (window->frame, &borders);
else
meta_frame_borders_clear (&borders);
Sometimes, the else part was omitted and we were unknowingly using
uninitalized values for OR windows. Clean this up by just testing
for a NULL frame in meta_frame_calc_borders and clearing for the
caller if so.
https://bugzilla.gnome.org/show_bug.cgi?id=643606
Mutter originally started out with the idea that only a subset of the total
API was exposed to plugins, so some APIs are duplicated on MutterPlugin.
We've long since abandoned that idea; remove these wrappers.
https://bugzilla.gnome.org/show_bug.cgi?id=671103
The experimental Cogl api cogl_texture_pixmap_new() was recently changed
so it now expects an explicit CoglContext argument and it can also
return exceptions now via a GError. This patch updates mutters use of
the api accordingly.
This was preventing Clutter from running its dispose, preventing
it from being destroyed correctly. While a major bug and possibly
big memory leak, the most obvious effect was the message that Clutter
spat out:
Clutter-CRITICAL **: clutter_actor_iter_next: assertion `ri->age == ri->root->priv->age' failed
Since we never disposed the actor correctly, it was never removed
from its parent, and the age wasn't updated correctly.
When we were shaping the window with a cairo region, there was an easy
optimization to restrict painting only to the pixels we were going to
actually draw. With rounded corners, the amount of work we have to do
figure out what pixels isn't worth the small savings of not drawing the
completely transparent parts of the corners, so remove this optimization,
and the supporting meta_shaped_texture_get_visible_pixels_region()
https://bugzilla.gnome.org/show_bug.cgi?id=657639
ClutterTexture has many features that we simply don't use and don't make
sense for a subclass with custom drawing. Deriving directly from ClutterActor
simplifies our code by avoiding workarounds and makes things more robust.
Additionally, make it public. GNOME Shell was already assuming that any
MetaShapedTexture was also a ClutterTexture, and we need to replace these
bits with new API for GNOME Shell to use.
https://bugzilla.gnome.org/show_bug.cgi?id=660941
