The pixman renderer can not be disabled and other parts of wlroots
do not carry their own dependency of libpixman around. Use a single
global dependency which also satisfies the pixman renderer.
The "restrict" keyword can be used to indicate that no other
pointer will be used to access a chunk of memory while the
restricted pointer is alive. If that promise is not upheld,
undefined behavior is triggered.
It may be difficult to ensure this property, and the property may
be brittle - becoming invalid as code evolves. Just like "inline",
let's just leave optimizations up to the compiler to figure out.
xwayland_surface_associate() asserts that the surface has not yet
been associated yet. Arbitrary clients can send these messages,
don't abort when that happens.
This field is difficult to use correctly, its meaning depends on
format.
xcb docs read:
> You should use the corresponding accessor instead of this field.
Replace all uses with the safe accessor.
This fixes potential out-of-bounds array accesses when the format
field isn't what we expect.
Add `wlr_backend_get_libinput` getter, which returns a direct
handle to `struct libinput`.
Exposing the libinput context will allow compositors to load
libinput plugins after creating a `wlr_backend`.
Lua plugins are supported since libinput 1.30.0.
In handling scene buffer output updates, wlroots would send a leave event to
all entered outputs, even those that the scene root for the scene output update
event did not own. Leaving the output list inaccurate.
Sending leave events only for the given scene introduces a problem, though:
existing logic to de-duplicate leave events stops us from sending a leave event
when we leave all the outputs in a scene, and when the surface then becomes
visible in another scene, the frame pacing output cannot be selected
accurately. This breaks screen capture for off-screen windows in sway.
So, let us also mark outputs that would have been left but were spared by the
deduplication logic as "suspended" indicating they are ineligible as frame
pacing outputs.
Fixes: https://github.com/swaywm/sway/issues/9094
The previous commit adds a synthetic NV12 render format to the set, but
it is contingent upon the presence of the R8 and GR88 render formats.
Signed-off-by: Andri Yngvason <andri@yngvason.is>
This needs to be handled specifically for NV12 because GBM does not know
how to allocate NV12 buffers. The approach I've taken is to allocate a
linear R8 buffer for storage and then to import it as NV12 with an
offset for the chroma plane.
Signed-off-by: Andri Yngvason <andri@yngvason.is>
As mentioned in the previous commit message, we can't create an RBO out
of an NV12 buffer in GL ES2.0. Instead, we render in 2 passes to 2
separate RBOs.
This could be made more generic by having a lookup table for the
parameters that need to be set for each plane for any given format, but
as of yet, I see no practical reason for implementing any other kind of
YCbCr target buffer rendering as NV12 seems to be the only format that's
commonly supported by hardware video encoders.
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Rendering to NV12 buffers is not directly supported in GL ES2.0, but can
be implemented by rendering in 2 passes to 2 different EGL images.
This change makes provisions for multiple EGL images inside a
wlr_gles2_buffer and adds a special case for mapping NV12 buffers to
multiple EGL images.
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Fix a memory leak when waiter_init fails in wlr_drm_syncobj_merger_add(),
and prevent the old sync_fd from being closed when sync_file_merge fails
in wlr_drm_syncobj_merger_add_sync_file().
This reverts commit 02abf1cd28.
The change doesn't make sense. It causes a use-after-free when trying
to read the pixel data of the icon. The docs clearly state to use
'xcb_ewmh_get_wm_icon_reply_wipe()' when using the function which
correctly frees the reply *after* processing the pixel data.
If a very large number of clip rects are accumulated in rect_union_add,
rect_union_evaluate can end up being disproportionately expensive, and
as an extreme numbers of clip rects are not beneficial for drawing, this
is without any benefit.
Limit the number of rects to 1024 in rect_union_add, switching over to
bounding box mode instead when the limit is exceeded. This leads to a
small 70% reduction in CPU time in the Vulkan renderer on the
stacked/clip200/1024 benchmarks.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
rect_union_add takes a pixman_box32_t by value, and passes it along by
value to internal helpers. render_pass_mark_box_updated which is the
only caller receives the pixman_box32_t by reference, so just plumb it
through that way.
Results in a 13% improvement in CPU time when using the Vulkan renderer
on the stacked/clip200/1024 benchmarks on my machine.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Similar to what we have already done for gles2. To simplify things we
use the staging ring buffer for the vertex buffers by extending the
usage bits, rather than introducing a separate pool.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
We are spending quite significant CPU time walking through the clip
rects, taking a pixman box, converting it to a wlr box, intersecting it
and ultimately converting it back to a pixman box before adding it to
the rect union.
Just intersect the clip region once ahead of time, and use pixman boxes
the entire way. This also makes it easy to bail early if nothing
intersects.
Gives a small 97.95% reduction in CPU time for the Vulkan renderer in
the grid/clip200/1024 benchmark.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Implement a ring-buffer that uses timeline points to track and release
allocated spans. We add larger ring-buffers when it fills, and remove
them when they have been unused for many collection cycles.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
