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.
xkb_keymap_new_from_string() assumes that the string is
NULL-terminated, but we don't check this so the function might
access outside the mmap'ed region. Use the safer
xkb_keymap_new_from_buffer() function.
Reported-by: Julian Orth <ju.orth@gmail.com>
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/work_items/4072
Actually send the modifiers event when there is no keymap set.
Compositors may need lower-level "raw" access to the key/modifiers
events from the backend. Currently it is impossible for a compositor
to get modifier events from the backend without them being filtered
through an xkb_state controlled by wlroots.
I need this feature for river in order to fix some keyboard state
synchronization bugs.
Note that setting a keymap resets the modifiers so I don't think setting
wlr_keyboard->modifiers directly here is a concern.
Before this patch the pixman renderer would use "constant padding"
for bilinear scaling which meant that the edges would either be dark
or turn transparent. The effect was most obvious when trying to scale
a single row buffer to a height like 100. The center would have the
desired color but the edges to both sides would fade into transparency.
We now use PIXMAN_REPEAT_PAD which clamps out-of-bound pixels and
seems to match the behavior of the gles2 renderer.
Currently the width/height of the extents is too small if the first node
visited has position/dimensions 0,0,100,100 and the second node has
position/dimensions -20,-20,10,10.
In this case the current code calculates total extents as
-20,-20,100,100 but the correct extents are -20,-20,120,120.
References: https://codeberg.org/river/river-classic/issues/17
Uses the EXT version of VK_PIPELINE_COMPILE_REQUIRED in `vulkan_strerror` func since it requires
Vulkan 1.3, switch to VK_EXT_global_priority instead of VK_KHR_global_priority which is only
promoted to core in Vulkan 1.3 as well.
The returned fence is not required to be signalled at the earliest
possible time. It is not intended to replace the drm flip event, and is
expected to be signalled only much later
This changes the behavior of wlr_linux_drm_syncobj_surface_v1 to
automatically signal release of previous commits as they are replaced.
Users must call wlr_linux_drm_syncobj_v1_state_add_release_point or
wlr_linux_drm_syncobj_v1_state_signal_release_with_buffer to delay the
signal as appropriate.
Basic implementation of color representation in drm/atomic: when buffers
are presented for scanout which have color-representation data attached,
set the correct color encoding and range on the plane. If the plane
does not support color-representation then the commit will fail and the
caller can retry without color-representation.
When doing direct-scanout, if the surface has color-representation
metadata present then pass on that metadata to the output state.
Also, if a buffer has color representation IDENTITY+FULL then normalise
this to NONE+NONE which is equivalent.
Add color_representation to wlr_output_state, holding color
representation metadata about the primary buffer. This can be set
using wlr_output_state_set_primary_color_representation() and a
new enum value WLR_OUTPUT_STATE_COLOR_REPRESENTATION in
wlr_output_state.committed indicates when this data is present.
Also add color-representation to wlr_output, and discard
color-representation in wlr_output_state if it matches what's already
been committed to the output.
This guards against a crash where the server implements
wlr_ext_image_capture_source_v1_interface without setting .get_pointer_cursor().
In general, we should install a NULL check here because this is a crash
waiting to happen. Now, instead of crashing, the resource will be created and
the copy capture session will be stopped.
