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
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>
When locking surface state, surface_cache_pending will move the pending
surface state to a new, empty `wlr_surface_state`. This new surface
state will only contain the fields committed in the pending state, as
surface_state_move does not copy anything else.
surface_update_damage is called before we move state from pending to
current to merge buffer damage and surface damage, and it expects that
the pending surface state still contains prior committed details such as
scale and transform. This is not the case when we finally commit the
cached surface state.
Move surface_update_damage after surface_state_move and make it operate
purely on the current surface state.
Prior to this patch, when the client binds the manager, the existing
toplevel handles were notified in the opposite order of their creation,
as wl_list_insert() adds a new handle to the head of the list and
wl_list_for_each() iterates from head to tail.
