Use the correct pointer types for cogl objects. This avoids warnings
when including the cogl headers doesn't result in all the cogl types
being typedefs to void.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Emit a signal so that interested parties can recreate their FBOs and
queue a full scene graph redraw to ensure we don't end up showing
graphical artifacts.
This relies on the GL driver supporting the
NV_robustness_video_memory_purge extension and cogl creating a
suitable GL context. For now we only make use of it with the X backend
since the only driver with which this is useful is NVIDIA.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
We ignore all damage while a surface is frozen and queue a full
update instead once it's thawed. While not super efficient, this
isn't overly bad for the intended case of catching up with any
updates that happened during a compositor effect. However when
extended frame sync is used, surfaces are also frozen while the
client is drawing a frame, in which case the current behavior is
pretty damaging (pun intended), as we end up redrawing the entire
window each frame. To address this, keep track of the actual damage
we ignore and apply it when the surface is thawed.
https://bugzilla.gnome.org/show_bug.cgi?id=767798
The only time the surface pointer (priv->surface) may be NULL is when
the surface is unmanaged but still painting, possibly due to a unmap
animation or the like, so only guard handle this situation in the entry
points that may come from the stage painting.
https://bugzilla.gnome.org/show_bug.cgi?id=763431
Before this commit, on Wayland, the buffer rect would have the size of
the attached Wayland buffer, no matter the scale. The scale would then
be applied ad-hoc by callers when a sane rectangle was needed. This
commit changes buffer_rect to rather represent the surface rect (i.e.
what is drawn on the stage, including client side shadow). The users of
buffer_rect will no longer need to scale the buffer_rect themself to
get a usable rectangle.
https://bugzilla.gnome.org/show_bug.cgi?id=763431
While CoglError is a define to GError, it doesn't follow the convention
of ignoring errors when NULL is passed, but rather treats the error as
fatal :-(
That's clearly unwanted for a compositor, so make sure to always pass
an error parameter where a runtime error is possible (i.e. any CoglError
that is not a malformed blend string).
https://bugzilla.gnome.org/show_bug.cgi?id=765058
Each wl_surface.commit with a newly attached buffer should result in
one wl_buffer.release for the attached buffer. For example attaching
the same buffer to two different surfaces must always result in two
wl_buffer.release events being emitted by the server. The client is
responsible for counting the wl_buffer.release events and be sure to
have received as many release events as it has attached and committed
the buffer, before reusing it.
https://bugzilla.gnome.org/show_bug.cgi?id=762828
We can detect that these windows are already fully opaque, so allow them
to unredirect. Allows unredirecting Totem during video playback, giving
a significant speed boost.
We currently rely only on MetaWindowActor to update the mask
texture. This isn't good enough since we might get asked to use the
mask (e.g. via meta_shaped_texture_get_image() ) after having a new
texture size but before MetaWindowActor decides to update the mask in
which case we might crash since cogl_texture_new_from_sub_texture()
might fail with an early return such as
Cogl-CRITICAL **: cogl_sub_texture_new: assertion 'sub_x + sub_width
<= next_width' failed
https://bugzilla.gnome.org/show_bug.cgi?id=762639
CSD X11 clients and Wayland clients don't have a window frame drawn by
the compositor to flash. So instead of flashing the whole screen when
configured to just flash the window, flash just the window region.
https://bugzilla.gnome.org/show_bug.cgi?id=763284
Some windows, like Chromium and Steam, are technically CSD in that they
don't want a system titlebar and draw their own, but we should still
provide them with a shadow.
If a queued event is being processed after the surface is
destroyed, trying to access the window associated with the surface
will lead to a segmentation fault.
This patch avoids the crash by first checking if the surface is not null.
https://bugzilla.gnome.org/show_bug.cgi?id=754715
Some backgrounds don't fully fill the screen. For those backgrounds
it's important to paint a color behind them to fill in the gaps.
This commit checks whether or not the background image textures take
up the entire monitor, and in the event they don't, draws a color
behind them (such as it would do if the background were
translucent).
https://bugzilla.gnome.org/show_bug.cgi?id=754476
meta_background_get_texture only draws the bottom image texture
if
1) the blend factor leaves the top image translucent
or
2) the top image is translucent from alpha
The latter case doesn't actually matter since we're using REPLACE
on the top image texture.
This commit drops the unnecessary check for the second case and
applies demorgans law to the conditional for clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=754476
Since mutter has two X connections and does damage handling on the
frontend while fence triggering is done on the backend, we have a race
between XDamageSubtract() and XSyncFenceTrigger() causing missed
redraws in the GL_EXT_X11_sync_object path.
If the fence trigger gets processed first by the server, any client
drawing that happens between that and the damage subtract being
processed and is completely contained in the last damage event box
that mutter got, won't be included in the current frame nor will it
cause a new damage event.
A simple fix for this would be XSync()ing on the frontend connection
after doing all the damage subtracts but that would add a round trip
on every frame again which defeats the asynchronous design of X
fences.
Instead, if we move fence handling to the frontend we automatically
get the right ordering between damage subtracts and fence triggers.
https://bugzilla.gnome.org/show_bug.cgi?id=728464
The spec says:
"A server should avoid signalling the frame callbacks if the surface is not
visible in any way, e.g. the surface is off-screen, or completely obscured
by other opaque surfaces."
We actually do have the information to do that but we are always calling
the frame callbacks in after_stage_paint. So fix that to only call when
when the surface gets drawn on screen.
https://bugzilla.gnome.org/show_bug.cgi?id=739163
The compositor maintains a ring of shared fences with the X server in order to
properly synchronize rendering between the X server and the compositor's GPU
channel. When all of the fences have been used, the compositor needs to reset
one so that it can be reused. It does this by first waiting on the CPU for the
fence to become triggered, and then sending a request to the X server to reset
the fence.
If the compositor's GPU channel is busy processing other work (e.g. the desktop
switcher animation), then the X server may process the reset request before the
GPU has consumed the fence. This causes the GPU channel to hang.
Fix the problem by having the compositor's GPU channel trigger its own fence
after waiting for the X server's fence. Wait for that fence on the CPU before
sending the reset request to the X server. This ensures that the GPU has
consumed the X11 fence before the server resets it.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728464
If GL advertises this extension we'll use it to synchronize X with GL
rendering instead of relying on the XSync() behavior with open source
drivers.
Some driver bugs were uncovered while working on this so if we have
had to reboot the ring a few times, something is probably wrong and
we're likely to just make things worse by continuing to try. Let's
err on the side of caution, disable ourselves and fallback to the
XSync() path in the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=728464
When a client sets an input region or a opaque region to NULL, it
should still be considered a change to the corresponding region on the
actor. This patch makes sure this state is properly forwarded.
https://bugzilla.gnome.org/show_bug.cgi?id=753222
Keep the active position state in its original coordinate space, and
synchronize the surface actor with it when it changes and when
synchronizing the rest of the surface state, in case the surface scale
had changed.
https://bugzilla.gnome.org/show_bug.cgi?id=745655
Whenever a MetaSurfaceActor is painted, update the list of what outputs
the surface is being drawed upon. Since we do this on paint, we
effectively avoids this whenever the surface is not drawn, for example
being minimized, on a non-active workspace, or simply outside of the
damage region of a frame.
DND icons and cursors are not affected by this patch, since they are not
drawn as MetaSurfaceActors. If a MetaSurfaceActor or a parent is cloned,
then we'll check the position of the original actor again when the clone is
drawn, which is slightly expensive, but harmless. If the MetaShapedTexture
instead is cloned, as GNOME Shell does in many cases, then these clones
will not cause duplicate position checks.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
We may access it during painting even if it has been freed. For now,
manually unset it during the MetaWaylandSurface cleanup; in the future
make MetaWaylandSurface a GObject and make the surface pointer a weak
reference.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
The elementary guys would like this as an API, and I don't see any
reason to refuse -- this is quite nice shadow painting code :)
For some reason, gobject-introspection can't seem to cope with
MetaWindowShape. I'll look into it a bit later, but for now, mark
the function it has trouble with as (skip).
It seems that when translated, paint_offset and actor_offset will always
be the same, so our translation of the clip group won't work. For now,
until I figure out what's going on here, just use the painting offset,
since that what seems to make sense to me.
I didn't write this code, though, so I don't know why the actor's
allocation was involved in this computation at all.
I tested briefly with clones (magnifier, manual cloning through the
looking glass) and couldn't find any other artifacts, so I'm going to do
this for now.
A much less hacky version of maximize / unmaximize is reimplemented
in terms of this, but it could also eventually be used for fullscreen /
unfullscreen, and tile / untile.
The comment explains it better, but Clutter tries to be smart and
repaint actors when their allocations change. Since the window group's
allocation changes when windows move around, this means that moving a
window will always cause a full-stage repaint, which is super slow.
Hack around this for now.
