`meta_rectangle_transform()` is used in the stack to *compensate* for a
`MetaMonitorTransform` applied to a output, not to apply it again.
Change the function accordingly.
Context:
Experimenting with direct scanout on offscreen-rotated outputs revealed
that the 90/270 degree cases were actually interchanged.
Further digging revealed that we use `meta_rectangle_transform()` with
those values swapped in every single case, papering over the issue.
Either a unintuitive and unexplained `meta_monitor_transform_invert()`
was added, in which case "flipped" values would be wrong, or, in case
of Wayland buffer transforms, the values were swapped by interpreting
the Wayland enums accordingly, see commit 8d9bbe10.
Swapping the 90/270 degree values in `meta_rectangle_transform()`:
1. fixes hardware cursor positioning with flipped output transforms
2. fixes rendering issues with offscreen-rotated flipped output transforms
3. allows us to drop unexplained `meta_monitor_transform_invert()`s in
follow-up commits
4. allows us to make `META_MONITOR_TRANSFORM` and `WL_OUTPUT_TRANSFORM`
enums match again (reverting 8d9bbe10, as already done)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
We may need to check if rectangles region has adjacent neighbors and
so if there are no gaps in between monitors.
This can be done by checking if each monitor is adjacent to any other in
the same region.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
MetaGravity is an enum, where the values match the X11 macros used for
gravity, with the exception that `ForgetGravity` was renamed
`META_GRAVITY_NONE` to have less of a obscure name.
The motivation for this is to rely less on libX11 data types and macros
in generic code.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
In order to scale a rectangle by a double value, we can reuse a ClutterRect
to do the scale computations in floating point math and then to convert it back
using the proper strategy that will take in account the subpixel compensation.
In this way we can be sure that the resulting rectangle can fully contain the
original scaled one.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/469
GList's used in legacy code were free'd using a g_list_foreach + g_list_free,
while we can just use g_list_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
Fixes condition duplicated:
/* If a contains b, just remove b */
if (meta_rectangle_contains_rect (a, b))
{
delete_me = other;
}
/* If b contains a, just remove a */
else if (meta_rectangle_contains_rect (a, b))
{
delete_me = compare;
}
Closes https://gitlab.gnome.org/GNOME/mutter/issues/480
Meta rectangles are integer based while clutter works in floating coordinates,
so when converting to integers we need a strategy.
Implement the shrink strategy by ceiling the coordinates and flooring the width,
and the grow strategy reusing clutter facility for this.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.
https://gitlab.gnome.org/GNOME/mutter/issues/447
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
testboxes was a binary that did unit testing, but it wasn't integrated
to the test system, so in effect, it was never run. Instead integrate it
into the other mutter unit tests. This includes changing a few of
meta_warning()s into g_warning()s so that the GTest framework can handle
them.
Logical monitors in a configuration must be adjecent to each other,
meaning there will be at least one pixel long side touching some other
logical monitor.
The exception to this is when there is only one logical monitor, which
cannot be adjecent to any other.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
They are already effectively interchangeable so this should reduce
pointless casts.
Just like in GDK though, we need to keep the old definition for
instrospection to be able to include the struct's fields.
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Like the _NET_WM_STRUT/_NET_WM_STRUT_PARTIAL client properties,
_NET_WORKAREA is defined in terms of screen geometry rather than
taking individual monitors into account. However we do want to
allow system chrome to be attached to a monitor edge rather than
a screen edges under some circumstances. As not all clients can
be assumed to deal gracefully with the resulting workarea, use
those "struts" only internally for constraining windows, but
ignore them when exporting _NET_WORKAREA.
https://bugzilla.gnome.org/show_bug.cgi?id=730527
Mark that the the third argument to meta_rectangle_union and
meta_rectangle_intersect is an (out) argument that should be created
by the language binding.
https://bugzilla.gnome.org/show_bug.cgi?id=645247
If mutter is going to be a "real" library, then it should install its
includes so that users can do
#include <meta/display.h>
rather than
#include <display.h>
So rename the includedir accordingly, move src/include to src/meta,
and fix up all internal references.
There were a handful of header files in src/include that were not
installed; this appears to have been part of a plan to keep core/,
ui/, and compositor/ from looking at each others' private includes,
but that wasn't really working anyway. So move all non-installed
headers back into core/ or ui/.
https://bugzilla.gnome.org/show_bug.cgi?id=643959
Remove --allow-unprefixed option to the scanner, and fix resulting
problems:
* theme.h and boxes.h are split into a main -header and a private
header that includes stuff that is not generally useful and
hard to introspect. Merge theme-parser.h into theme.h.
* meta_display_get_atom() and meta_window_get_window_type_atom()
are marked as (skip)
* Fix annotation: (element-type Strut) => (element-type Meta.Strut)
https://bugzilla.gnome.org/show_bug.cgi?id=632494
Cleanly build with --warn-fatal. Implementation:
* Liberally apply (skip) where the API is clearly C only, e.g. uses
XLib. The theming code and MutterPlugin are skipped too.
* Add missing (transfer) and (element-type) annotations
For a few functions that had a comment, I turned it into gtk-doc, but
I didn't (with a few exceptions) try to write new documentation in
this pass.
Export a boxed type for MetaRectangle; this is mostly of interest
because GdkRectangle has been turned into a typedef for
cairo_rectangle_int_t which causes massive problems for using it from
gobject-introspection based language bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=623335
