1
0
Fork 0
Commit graph

16 commits

Author SHA1 Message Date
Jonas Dreßler
b770ea606a background-content: Optimize rounded clipping shader a bit
We're using the gtk4 shader for rounded rect clipping here, and gtk just
introduced a small optimization to make this shader a bit faster, so
let's do the same.

See 57e354c297

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1774>
2021-03-11 22:59:07 +01:00
Jonas Ådahl
3bbfaa03b3 background-content: Fix pipeline cache size
The cache had the size 9, which was "big enough" in the past, but when
more ways pipelines could be constructed, the size was not enough. The
need to increase the cache size was hard to spot though, since adding
pipeline flag didn't give any hints about the cache being directly tied
to these flag values.

So, when enough flag bits were set when attempting to retrieve and put a
pipeline in the cache, it'd instead overwrite some arbitrary stack
memory, which would sooner or later result in a memory corruption
induced crash. Valgrind could not detect this particular memory
corruption, as it messed up stack memory, not e.g. freed heap memory, so
it instead got confused and thought plain stack values were unreadable.

Fix these two issues by making the cache size the combination of all
pipeline flags + 1, so that we can safely put any flag combination in
the cache.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1747>
2021-02-24 15:59:58 +00:00
Jonas Dreßler
5527b6e483 background-content: Add support for rounded clipping when drawing
We're going to round the workspace backgrounds in the new overview for
gnome-shell 40.

So far corner-rounding was only possible for StWidgets because the
rounded clipping was done using cairo drawing. We now need rounded
clipping for ClutterActors too because backgrounds are drawn using
ClutterActors (or more specifically a ClutterContent). To implement
that, first a ClutterOffscreenEffect subclass together with a fragment
shader from GSK (see gskSetOutputColor() [1] in the GSK GL renderer
code) was investigated, and while that was generic and worked quite
well, it was extremely slow for the case of drawing wallpapers because
of all the FBOs that had to be allocated.

This is the new, more performant approach: Use the same fragment shader,
but perform the rounded clipping right in MetaBackgroundContent while
we're painting the wallpaper. This has almost no performance impact,
with the downside of not being a generic solution.

To allow for rounded clipping not only at the edges of the wallpaper,
but using any given bounding rectangle, the API exposes not only the
radius, but also a bounding rect.

[1] https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gsk/resources/glsl/preamble.fs.glsl

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1717>
2021-02-18 20:26:42 +00:00
Daniel van Vugt
c7a0ab3eb8 background-content: ceilf the actor size instead of roundf
We want the bounding box so `ceilf` seems more appropriate. It was
only written using `roundf` before as a workaround for inaccuracies
coming out of `clutter_actor_get_transformed_size` that would have
tricked `ceilf` into landing on the wrong integer. But that's since
been fixed by 67cc60cbda so we can use `ceilf` now.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1532
2020-10-27 19:33:30 +00:00
Daniel van Vugt
a24b2f4b0f background-content: Assume background clones are always transformed
Because clones may not have identical geometry to their source actors.
So we can't use the geometry of the source actor to decide to take the
more optimized (more clipped) path.

Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1480
2020-10-23 22:54:25 +00:00
Daniel van Vugt
64d34a7648 background-content: Apply Cullable clipping even in the transformed case
Just like we used to before 30809665d8.

Because in some cases `clip_region` is able to shave off an extra pixel
from the edge of the redraw rectangle(s). And not shaving that off was
making the background rendering inconsistent with shaped-texture, causing
occasional off-by-one artefacts. Now both shaped-texture and
background-content agree on the clip region again that doesn't happen.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1443

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1464
2020-10-01 18:13:15 +08:00
Daniel van Vugt
86af337585 background-content: Use redraw_clip when culling is unavailable
When in the overview culling via `self->clip_region` is unavailable.
The region is `NULL` because the paint call has not originated from a
`WindowGroup`, because the overview does not use `WindowGroup`.

So the main wallpaper was being painted in full while in the overview.
That's a waste of effort because `redraw_clip` is going to be used to
stencil/scissor out only the parts that are changing. We don't need to
paint *most* of the wallpaper, only the parts behind anything changing.

For the overview this reduces GPU power usage (intel_gpu_top) roughly
10% and reduces render times almost as much.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1363
2020-08-30 12:04:07 +00:00
Daniel van Vugt
30809665d8 background-content: Explicitly distinguish stage space from actor space
`meta_background_content_paint_content` was mixing two different
coordinate systems in `actor_pixel_rect`. It was initialized with
actor-local coordinates and then `if (self->clip_region)` would be
treated as stage coordinates. This worked because `self->clip_region`
was only non-NULL outside of the overview where both coordinate systems
were the same. So it always got the right answer, possibly by accident.

In order to enhance the function however we will need to know which
coordinate system we're working in, so now we make it explicit.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1363
2020-08-30 12:04:07 +00:00
Daniel van Vugt
0efecc1dc5 background-content: Don't set up pipeline unless it's needed
There was still a possibility we might return and not paint anything
so there's no need to set up the pipeline before that.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1363
2020-08-30 12:04:07 +00:00
Daniel van Vugt
ecaaccb064 background: Use NEAREST filtering when the texture is the monitor resolution
That was obviously always the intention, but it didn't work when the
display was scaled. My 3840x2160 monitor with a 3840x2160 texture was
being rendered with LINEAR filtering.

It seems the `force_bilinear` flag was TRUE when it should be FALSE.
Because a texture area that's an integer fraction of the texture
resolution is still a perfect match when that integer is the monitor
scale. We were also getting:

`meta_actor_painting_untransformed (fb, W, H, W, H, NULL, NULL) == FALSE`

when the display was scaled. Because the second W,H was not the real
sampling resolution. So with both of those issues fixed we now get
NEAREST filtering when the texture resolution matches the resolution it's
physically being rendered at.

Note: The background texture actually wasn't equal to the physical monitor
resolution prior to January 2020 (76240e24f7). So it wasn't possible to do
this before then. Since then however, the texture resolution is always
equal to the physical monitor resolution.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1346
2020-07-08 07:26:50 +00:00
Daniel van Vugt
32dbcd9352 background-content: Mipmap background texture rendering
gnome-shell displays workspace previews at one tenth scale. That's a
few binary orders of magnitude so even using a LINEAR filter was
resulting in visible jaggies. Now we apply mipmapping so they appear
smooth.

As an added bonus, the mipmaps used occupy roughly 1% the memory of
the original image (0.1 x 0.1 = 0.01) so they actually fit into GPU/CPU
caches now and rendering performance is improved. There's no need to
traverse the original texture which at 4K resolution occupies 33MB,
only a 331KB mipmap.

In my case this reduces the render time for the overview by ~10%.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1416

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1347
2020-07-07 16:15:28 +08:00
Daniel van Vugt
9823a0f6c9 background-content: Fix an x/y mixup
Fortunately the coordinate is local and always (0,0) so it didn't
break anything.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1341
2020-06-30 18:37:35 +08:00
Jonas Ådahl
932340a989 background-content: Shut up warning
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1303
2020-06-10 10:42:18 +02:00
Georges Basile Stavracas Neto
ca0156e9a7 background-content: Render background slices relative to actor box
The current code assumes that the actor will always have the same
size and position of the background texture, but part of the implicit
contract of being a ClutterContent is being able to render itself
at any given actor, at any given size.

For example, if the current code is given an actor with 0x0+100+100
as geometry, and no clipped region, it'll render not the whole
background, but the 0x0+100+100 rectangle of the background. In
practice, the actor geometry acts like a "clip mask" over the
background texture, due to the assumption that the actor will
always have the same size of the monitor.

Make the calculation of the texture slices relative to the actor
box.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1302
2020-06-09 17:07:02 -03:00
Georges Basile Stavracas Neto
6d75b4fc53 background-content: Simplify method call
It's always passing the same pipeline and texture rect, simplify
by passing the MetaBackgroundContent instance itself.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1302
2020-06-09 17:07:02 -03:00
Georges Basile Stavracas Neto
a1b3d1a2a7 Introduce MetaBackgroundContent
MetaBackgroundContent is a ClutterContent implementation
that can render a background to any attached actor. Right
now, it preserves all the properties and the rendering
model of MetaBackgroundActor.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1302
2020-06-09 17:07:02 -03:00