This has been introduced way back in
be297d9d14 but is never used anywhere.
If compositors want to save the old dimensions before reacting to a
fullscreen or maximize event they can just grab the sizes within their
event handlers instead.
The old code to render transformed textures with pixman would run
composite over the whole output regardless of the texture size. When
rendering something small this caused a huge performance hit.
Rewrite the transform branch of render_pass_add_texture to:
- Only composite over the rectangle we're drawing to
- Generally try to make things a lot clearer and some comments
Fixes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3832
This change makes it possible to support both the direct srgb-format
pipeline and indirect (color-managed, or non-srgb-format) pipeline
for the same render buffer.
Fix source crop in the pixman render backend. It was being applied by
using a source offset as arguments to pixman_image_composite32(). But
this is wrong because the source crop should get applied before all the
other transforms, not after them (or at least this is how it works in
the other wlroots render backends). Instead, apply the source crop as
yet another matrix transform when we're doing transforms (Or keep it the
same as previously if there's no other transforming going on).
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3830
The translations for flipped offsets were set the same as non-flipped
ones which was totally wrong and meant that any textures with
flipped-transforms rendered entirely outside the viewport and were
basically invisible.
Instead of having separate getters for shm formats and DMA-BUF
formats, use the same pattern as wlr_output_impl.get_primary_formats
with a single function which takes buffer caps as input.
Clients may, for example, commit an exclusive zone larger than the
output dimensions. Compositors must handle this gracefully, which likely
requires more work on the compositor side but returning a usable area
with negative width or height in wlr_scene_layer_surface_v1_configure()
is nonsensical.
Pre-multipled sRGB values need to be un-multiplied before conversion
to linear and then re-multiplied after. Compare shaders/texture.frag.
This fixes an issue in labwc where titlebar corners (rendered as
ARGB textures) did not match the rest of the titlebar (rendered as
a solid wlr_scene_rect).
Note: 0.17 has other instances in render/vulkan/renderer.c that need
the same fix.
Our multi-gpu path currently needs to blit a buffer in order to have a
primaryfb to add to the commit. This is expensive, and we skip it
entirely during test commits. This in turn also means that we skip tests
commits entirely for such outputs, outside our own basic tests.
Backend-wide commits missed this check, and tried to perform test
commits for multi-gpu outputs despite no primaryfb having been attached,
making them always fail. Add the same exception as we have in the
per-connector commit-test.
As of currently, when an xcursor theme depends on itself or another theme
that will eventually depend on it, `xcursor_load_theme` will recurse
infinitely while processing the inherits.
This change introduces a stack-allocated linked list of visited nodes
by name, and skips any already visited nodes in the inherit list.
Side effects:
* Since the linked list is stack-allocated, there is a potential for an
overflow if there is a very long list of dependencies. If this turns out
to be a legitimate concern, the linked list is trivial to convert to
being heap-allocated.
* There is an existing linked list (technically doubly linked list)
implementation in the wayland codebase. As of currently, the xcursor
codebase does not refer to it. Consequently, this change writes a
minimal single linked list implementation to utilize directly.
This changeset is based on the merge request in wayland/wayland!376.
The xcursor code is mostly shared between the two.
This changeset diverges the files slightly due to stylistic differences
between the repositories, but the logic is identical.
Signed-off-by: Chloé Vulquin <toast@bunkerlabs.net>
When a wlr_gamma_control client calls set_gamma, we allocate a LUT based
on the value returned from wlr_output_get_gamma_size at the time of the
call.
If the output is off and has no CRTC, such as if gamma changes in the
background while a display is disabled for idle reasons,
wlr_output_get_gamma_size returns 0. This leads to a zero-sized table,
which the drm backend interprets as a request to reset gamma tables to
their default.
Store the gamma size when the gamma control was created. Even if the
size changes, this is the size the client was sent and uses to create
the LUTs it sends.
Per comments in util/box.h, the width and height of a wlr_box are
exclusive; that is, for a 100x100 box at (0,0), the point (99,99) is
inside it while the point (100,100) is outside it.
Thus mathematically, there exists no single closest point to the
bottom-right corner of the box while remaining inside it. You can
construct an infinite series approaching the limit, such as {(99,99),
(99.9,99.9), (99.99,99.99)...}, but since the intervals are half-open,
there is no "last" point.
wlr_box_closest_point() must therefore define an arbitrary "closest"
point. For points below and to the right of the box, the current
implementation returns (box.x + width - 1, box.y + height - 1). Let's
continue to do this.
However, the current implementation is non-linear: with the example
100x100 box, it will return an input point of (99.9,99.9) unchanged, but
for an input point (100.1,100.1) the returned point will jump back to
(99.0,99.0).
In practice, this non-linearity results in strange behaviors when
driving the mouse cursor to a screen corner. On a 1920x1080 display for
example, driving the cursor quickly to the bottom-left corner results in
a position of exactly (0,1079). Continuing to slowly nudge the cursor
downward results in the position jumping between (0,1079) and other,
fractional coordinates such as (0,1079.88).
The fractional coordinates expose some client/toolkit-side bugs (which,
to be clear, should be fixed on the client side), but IMHO the wlroots
behavior is also inconsistent and wrong -- when I drive the mouse cursor
into the corner of the screen, it should come to a stop at a fixed
position, not jitter around.
