By implementing support for `GdkDmabufTextureBuilder` and
`GstVideoInfoDmaDrm`. This allows zero-copy video playback on Wayland
when paired with hardware video decoding.
Can be tested with `gtk4-demo --run=video_player`
We keep various pieces of double-buffered state on our side,
and then explicitly sync it over to the Wayland side.
Add a function to find out if we have any.
Count dead pixels in textures (ie the number of pixels in GPU
textures that are no longer backed by an alive GdkTexture object),
and when the there's too many, do a gc before rendering the next
frame.
Count the uses of cached texture - from the device (via the linked
list) and from the texture (via render data / weak ref), and only
free the item once the use count reaches zero.
Instead of forever running a timeout to do gc, ensure the timeout
is scheduled whenever we render a frame (this is done by calling
gsk_gpu_device_maybe_gc () before gsk_gpu_frame_render (), and
gsk_gpu_device_queue_gc () after).
Read the GSK_CACHE_TIMEOUT environment variable to override the
default 15s timeout for cache gc. This is mainly meant for debugging.
Since we don't really need two knobs, reuse the gc timeout value
for the max age of items too.
The node processing wasn't skipping 0-size nodes when using the
uber shader, leading to assertions down the road. Since the ngl
renderer doesn't use uber shaders, this only affects vulkan.
Test included.
Fixes: #6370
When we don't have an embedded font file via a url, then we want
to parse fonts "as normal", i.e. allow fallback for aliases like
"Monospace 10". This was broken when the url support was added.
Make it work again.
Update affected tests. In particular, the output of the text-fail
test goes back to be the same it was before the url changes.
GL needs version 4.2 before it supports explicit bindings. We use GLES
usually, and Mesa supports GL 4.6, so we didn't hit this case before.
However, MacOS does use GL and Mac OS is stuck on GL 4.1.
Fixes#6363
The ngl renderer has good support for fractional scaling, so we
can enable this by default now.
If you are using the gl renderer, you can disable fractional
scaling with the
GDK_DEBUG=gl-no-fractional
environment variable.
The intent of this change to get wider testing and verify that the
new renderers are production-ready. If significant problems show
up, we will revert this change for 4.14.
The new preference order is ngl > gl > vulkan > cairo.
The gl renderer is still there because we need it to support gles2
systems, and vulkan still has some rough edges in application support
(no gl area support, webkit only works with gl).
If you need to override the default renderer choice, you can
still use the GSK_RENDERER environment variable.
See previous commit for an explanation of the problem.
This test actually draws a rounded border, but the rounding is clipped
away. What is remaining is the 4 corners of the border, where the
top/bottom color is red and the left/right color is green. But because
the bottom/right side has a width of zero, the result should be all red.
When a border side has a width of 0 but we're having rounded corners, we
draw content in the edges of that side, and naturally pick its color.
That is wrong though, when the width is zero, we're supposed to keep
using the color of the other side in that corner.
So do that.
Fixes the border-corner-zero-width-rendering.ui reftest.
The statement is not doing what it was meant to do.
gtk_list_item_manager_get_nth (self, position, &offset) returns the
tile for a given position, and if the tile maps to more than 1 item,
the offset indicates how far into that tile the given position is.
So position - offset would give us the position of this tile. It
doesn't make sense to subtract it from n_items.
Instead, we should be adding the offset to compensate for having
landed too early in the list, such that we successfully reach
position + n_items.
When there is a duplicate item in the hash table of deleted items, we:
1. Unparent the unparent the old `widget` value (gtk_widget_unparent is
passed as `GDestroyNotify value_destroy_func` for the hastable).
2. Set the new `widget` value in the hashtable.
3. Also set the same `widget` in the recycled queue.
This means the same widget is found in the 2 containers and, therefore,
the same widget may be returned twice by gtk_list_item_change_get().
Alternatively, this means we may reuse the item by taking it from the
hashtable and reassigning it to a tile, but then it ends up getting
unparented by gtk_list_item_change_finish(). Or we don't take it at
all and end up calling gtk_widget_unparent()` on it twice, which may
result in use-after-free on the second call the parent was holding the
last reference.
This was introduced by 76d601631d
Previously, gtk_list_item_manager_release_list_item() would just emit
the warning but otherwise do nothing. Let's restore that behavior.
We are failing to go from this:
[ BLUE ] [ RED ]
...to this:
[ BLUE GREEN YELLOW ] [ RED ]
...where '[' and ']' represent section header and footer.
Instead, the result is...
[ BLUE ] [ GREEN YELLOW ] [ RED ]
... despite the first 3 items belonging to the same section according
to the section model. This leaves the view in an inconsistent state
and, ultimately, to crashes the non-removed footer.
Indeed, when receiving items-changed(1,0,2), we call `append_items()`
which inserts a new tile before the tile at `1` (which was RED), and
then notices there is a HEADER right befo-re it, so it flags both it
and the corresponding FOOTER as unmatched:
[ BLUE ] ( GREEN-YELLOW RED )
... where '(' and ')' represent unmatched header and footer.
Problem is subsequent code in `release_items()` doesn't even touch
the section boundary footer-header pair ('] ('), because they are
belong in the tracked interval (visible items). And `ensure_items()`
proceeds to match the header with a new footer, producing the result
described above.
To handle this correctly, `append_items()` must delete the section
boundary, and flag as unmatched both the HEADER of the section before
and the FOOTER of section after (whose respective footer and header
has been marked for removal):
( BLUE . . GREEN-YELLOW RED )
... where '.' represents tiles marked for removal.
This way, `release_items()` will release the removed footer-header
section boundary, and `ensure_items()` is going to reinstate new
section remove the section boundary at the correct place, resulting
in the expected behavior:
[ BLUE GREEN YELLOW ] [ RED ]
We are not catching bugs when inserting if we're right at a boundary.
This because we never add or remove items from a section. We only ever
add or remove whole sections.
Introduce a test which inserts items at a random position inside of a
section.
Count how many dead pixels we have, and free the atlas if more than
half of its pixels are dead.
As part of this, change when glyphs are freed. We now keep them
in the hash table until their atlas is freed and we only do dead
pixel accounting when should_collect is called. This keeps the
glyphs available for use from the cache as long as are in the atlas.
If a stale glyph is sused, we 'revive' it by removing its pixels
from the dead.
This matches more closely what the gl renderer does.
If we gc a cached texture for which the GdkTexture is still alive,
the cached texture object will remain accessible via the render
data, so need to make sure not to leave a dangling pointer behind
here.
