With `META_MONITOR_TRANSFORM` values matching their `WL_OUTPUT_TRANSFORM`
counterparts, the definition from the Wayland spec applies: the
`META_MONITOR_TRANSFORM` value tells us how the output was rotated
and that the buffer was drawn by the client to compensate for that.
The matrix describes the transformation from surface- to buffer-
coordinates, so the operation we need here is the same one that
the client applied (not from buffer- to surface-coordinates, i.e.
the inverse).
While on it fix `FLIPPED_90` and `FLIPPED_270` to use the correct
axes: flip on the x-axis, rotation on the z-axis.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
When we get passed a "snippet" to the shaped texture, it's added as a
pipeline layer snippet to change how the source texture is sampled. When
we draw from a texture tower however we have allocated regular textures
which doesn't need any special layer snippet, so create separate
pipelines for those that doesn't use that snippet.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/528
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2278>
This was introduced by accident in commit 1467b6b02a
y-inverted textures in combination with shape masks appear to
be only commonly used with EGLstreams. However, as we draw the
shape mask ourselves, we don't want to apply the y-invert to it
as testified by the left over `cogl_pipeline_set_layer_matrix()`.
Note that we still allow to apply viemports and buffer transforms,
as the Xwayland mode setting emulation may use it (in fact only
the former, but it probably does not hurt to leave the later as well).
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1792
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1937>
When a viewport source rect or destination size is set, `stex->dst_width`
gives us the the cropped and/or scaled size. At this step, we need the
uncropped/unscaled size however.
Note: this is only ever relevant if buffer transform and viewport are
used together - otherwise the values are the same.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1836>
When using buffer transforms and viewports together, we currently
apply the transformation (read: rotation) first, resulting in
wrong buffer coordinates for viewport source rects.
Flip the order in whitch we apply our matrix transformations.
This can be tested e.g. via:
`weston-simple-damage --use-viewport --transform=flipped-180`
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1832>
When the texture size is invalidated using `invalidate_size()`, the new
size will only get calculated the next time `update_size()` is
called. This happens e.g. in `meta_shaped_texture_get_preferred_size()`
via `ensure_size_valid()`.
`update_size()` can chain up to `clutter_content_invalidate_size()`
as well as emitting a `size-changed` signal. If this happens during
layout, the result is a 'change the layout conditions during layout'
issue, causing heavy breakage in e.g. the Shell overview.
To fix this, expose `ensure_size_valid()` as API so callers can make
sure the texture has a valid size without creating redundant size
invalidations calls.
Note that if a buffer with a new size is attached we already trigger
`update_size()` explicitely, avoiding such situations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1799>
If only a viewport destination size is set, the noop viewport has
to take the buffer scale into account.
If a viewport source but no viewport destination size is set, the
destination size is that of the viewport source, not of the whole
texture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1786>
A first step towards abandoning the CoglObject type system: convert
CoglFramebuffer, CoglOffscreen and CoglOnscreen into GObjects.
CoglFramebuffer is turned into an abstract GObject, while the two others
are currently final. The "winsys" and "platform" are still sprinkled
'void *' in the the non-abstract type instances however.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1496
CoglMatrix already is a typedef to graphene_matrix_t. This commit
simply drops the CoglMatrix type, and align parameters. There is
no functional change here, it's simply a find-and-replace commit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Using opaque painting paths can have a big impact on painting performance.
In order to easily validate whether we use the opaque paths, add a opaque
(green) or blended (purple) overlay over painted areas if the
`META_DEBUG_PAINT_OPAQUE_REGION` `MetaDebugPaintFlag` is set.
You can do so in `lg` via:
`Meta.add_debug_paint_flag(Meta.DebugPaintFlag.OPAQUE_REGION)`
This can be helpful for application developers, as previously it was not
trivial to check whether e.g. Wayland or X11 opaque regions where
properly set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1372
We were setting the pipeline colour to all white (1.0, 1.0, 1.0, 1.0)
and so the default layer combine function multiplied each pixel
(R, G, B, A) by all ones. Obviously multiplying by one four times per
pixel is a waste of effort so we remove the colour setting *and* set
the layer combine function to a trivial shader that will ignore whatever
the current pipeline colour is set to. So now we do **zero** multiplies
per pixel.
On an i7-7700 at UHD 3840x2160 this results in 5% faster render times
and 10% lower power usage (says intel_gpu_top). The benefit is probably
much higher for virtual machines though, as they're no longer being
asked to do CPU-based math on every pixel of a window.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1331
In commit 4c1fde9d MetaCullable related code was moved out of
MetaShapedTexture into MetaSurfaceActor. While generally desirable,
this removed drawing optimizations in MetaShapedTexture for partial
redraws. The common case for fully obscured actors was still supposed
to work, but it was now discovered that it actually did not.
This commit revert parts of 4c1fde9d: it reintroduces clipping
to MetaShapedTexture but leaves all culling and actor related logic
in MetaSurfaceActor.
Thanks to Daniel van Vugt for uncovering the issue.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/850
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1295https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1326
One of the important classes in Mutter's handling of client textures is
the `MetaShapedTexture`. This commit adds a few gtk-doc comments which
explain its purpose, with special attention to the viewport methods.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1210
A paint flag affects a paint operation in ways defined by the flags.
Currently no flags are defined, so no semantical changes are defined
yet. Eventually a flag aiming to avoid painting of cursors is going to
be added, so that screen cast streams can decide whether to include a
cursor or not.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
We checked that the content size was appropriately painted in the stage,
but didn't take into account that the size of the sampled texture
region, meaning that when stage views were scaled, we'd think that we
would draw a texture scaled, as e.g. a 200x200 sized texture with buffer
scale 2 would have the size 100x100. When stage views were not scaled,
we'd apply a geometry scale meaning it'd end up as 200x200 anyway, thus
pass the check, but when stage views are scaled, it'd still be painted
as a 100x100 shaped texture on the stage, thus failing the
are-we-unscaled test.
Fix this by comparing the transformed paint size with the sampled size,
instead of the paint size again, when checking whether we are being
painted scaled or not. For example, when stage views are scaled, our
200x200 buffer with buffer scale 2, thus content size 100x100 will
transform to a 200x200 paint command, thus passing the test. For
non-scaled stage views, our 200x200 buffer with buffer scale 2 thus
content size 100x100 will also transform into a 200x200 paint command,
and will also pass the check, as the texture sample region is still
200x200.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/804https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1124
clutter_paint_node_get_framebuffer() fell back on
cogl_get_draw_framebuffer() when the root node didn't have a custom
get_framebuffer vfunc. As this relies on deprecated implicit Cogl stack
API, it needs to go away, so handle this in the caller that knows more
about the context.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
When painting, actors rely on semi global state tracked by the state to
get various things needed for painting, such as the current draw
framebuffer. Having state hidden in such ways can be very deceiving as
it's hard to follow changes spread out, and adding more and more state
that should be tracked during a paint gets annoying as they will not
change in isolation but one by one in their own places. To do this
better, introduce a paint context that is passed along in paint calls
that contains the necessary state needed during painting.
The paint context implements a framebuffer stack just as Cogl works,
which is currently needed for offscreen rendering used by clutter.
The same context is passed around for paint nodes, contents and effects
as well.
In this commit, the context is only introduced, but not used. It aims to
replace the Cogl framebuffer stack, and will allow actors to know what
view it is currently painted on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
This was wrongly introduced in 75cffd0ec4. As the comment above explains, we
only want to queue redraws in response to surface/buffer damage.
This triggered a full redraw when using DMA buffers on Wayland as we currently
create a new texture on every buffer_attach(), breaking partial invalidation.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/947
As the first step into removing Cogl types that are covered by
Graphene, remove CoglEuler and replace it by graphene_euler_t.
This is a mostly straightforward replacement, except that the
naming conventions changed a bit. Cogl uses "heading" for the
Y axis, "pitch" for the X axis, and "roll" for the Z axis, and
graphene uses the axis themselves. That means the 1st and 2nd
arguments need to be swapped.
Also adapt the matrix stack to store a graphene_euler_t in the
rotation node -- that simplifies the code a bit as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Move out updating of various shapes (input, opaque, shape) indirectly
from X11 to the corresponding X11 sub types of MetaWindowActor and
MetaSurfaceActor.
Also move fullscreen window unredirection code with it. We want to
effectively do something similar for MetaCompositorServer, but it will
work differently enough not to share too much logic.
While it would have been nice to move things piece by piece, things were
too intertwined to make it feasible.
This has the side effect fixing accidentally and arbitrarily adding
server side shadow to Wayland surfaces.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/727https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
It is opaque if the texture has no alpha channel, or if the opaque
region covers the whole content.
Internally uses a function that checks whether there is an alpha
channel. This API will be exposed at a later time as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
There were multiple bugs present after the ClutterContent transition.
Refactor `get_image` to:
- always assume surface coordinates for the clip
- return a cairo_surface in buffer size
- make the offscreen path take size arguments, so we can
easily change the assumption in get_image
- fix some clipping bugs on the way
https://gitlab.gnome.org/GNOME/mutter/merge_requests/758
Now that MetaShapedTexture is not a ClutterActor anymore, it does
not make sense to make it a MetaCullable semi-implementation. This
is, naturally, a responsibility of MetaSurfaceActor, since now
MetaShapedTexture is a ClutterContent and as such, it only cares
about what to draw.
Move the MetaCullable implementation of MetaShapedTexture to
MetaSurfaceActor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
By implementing ClutterContent, it is expected that
MetaShapedTexture can draw on any actor. However,
right now this is not possible, since it assumes
that the drawing coordinates and sizes of the actor
are synchronized with its own reported width and
height.
It mistakenly draws, for example, when setting an
actor's content to it. There is no way to trigger
this wrong behavior right now, but it will become
a problem in the future where we can collect the
paint nodes of MetaShapedTexture as part of other
ClutterContent implementations.
Use the allocation box passed by the actor to draw
the pipelines of MetaShapedTexture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
