Commit Graph

7 Commits

Author SHA1 Message Date
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