../render/color_lcms2.c: In function ‘wlr_color_transform_init_linear_to_icc’:
../render/color_lcms2.c:26:24: error: incompatible types when returning type ‘_Bool’ but ‘struct wlr_color_transform *’ was expected
26 | return false;
| ^~~~~
The mapping is shared between all users of the stage span, so it should
always map the whole thing and apply the allocation offset to the mapped
pointer.
The use of stage spans for 3dluts was missed when the new cached
mappings were introduced, meaning that it would try to map and unmap
memory that might already have a cached mapping.
Vulkan does not support mapping memory multiple times, so make sure the
3dlut code also uses the cached mapping to avoid segfaults after unmap.
It's cumbersome for compositors to guard every
wlr_color_transform_ref() or wlr_color_transform_unref() call
behind a #if WLR_HAS_COLOR_MANAGEMENT. Moreover, none of the LCMS2
types are used in our public API.
Instead, always install the color.h header, and add a stub for
wlr_color_transform_init_linear_to_icc().
e08d52bb introduced a bug when rotating by 90 or 270 degrees and doing
non-uniform scaling (different scale factor on X and Y axes). The scale
factor was calculated as the ratio between the src box and the rotated
dst box. But scaling is applied after rotation, so the scale factor
should instead be the ratio between rotated src box and dst box.
Reverts 77006e5565. It turns out this
change really breaks the labwc drop-shadow implementation (which relies
on scaling up single-pixel-wide buffers).
After reverting this there's still something subtley wrong with scaling
pixel locations (shown by `weston-scaler -b`) but I can't see an obvious
way to make both weston-scaler and labwc drop-shadows work in the same
way with pixman and gles2. I'll have a harder look at this but in the
mean time reverting this patch seems to make things less broken on
average.
UNDEFINED when used as source layout means that the contents of
the underlying memory becomes undefined. This isn't what we want
here: we don't want to mutate the imported pixel data.
The Vulkan spec isn't really clear what the proper value should be
here, but after discussing with driver developers [1] it seems like
UNDEFINED isn't the right one. The recommendation is to use GENERAL
instead.
[1]: https://github.com/ValveSoftware/gamescope/issues/356
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.
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.
The spec for GL_EXT_disjoint_timer_query says
> The GetInteger64vEXT command is required only if OpenGL ES 3.0 or later
> is not supported.
Some GLES 3.2 implementations like the proprietary mali driver on the
rk3566 based OrangePi advertise GL_EXT_disjoint_timer_query but lack
glGetInteger64vEXT. Use glGetInteger64v instead.
