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.
This is straightforward. If a texture hasn't been used for 4 seconds,
we consider it stale, and drop it the next time gc comes around.
The choice of 4 seconds is arbitrary.
Fixes: #6346
The gtk_at_spi_root_finalize() function currently chains up to
dispose(),
which is probably a copy-paste mistake since gtk_at_spi_root_dispose()
exists and also chains up to dispose().
Chain up to finalize().
Declaring a separate entry for Wayland and X11 is not very useful when
both just end up calling the same constructor. Also, in theory, this
can cause the Wayland entry to be picked up on X11 if both backends
are enabled (which is the common case).
Not that it matters, since the 'name' field is unused.
Nonetheless, clean it up to be a single entry
With the --repeat version of this test, Cairo needs to draw partially
clipped glyphs. However, there's a bug in Cairo where it doesn't account
for the subpixel positioning when clipping, so the glyphs get cut off at
the edge.
This is filed as https://gitlab.freedesktop.org/cairo/cairo/-/issues/821
Draw a grid of 21x21 box glyphs.
Each glyph is offset by n/20 pixels in the x and y direction.
The background color is carefully selected to be divisible by 16, so
that when the box glyph is subpixel positioned by 1/4th of a pixel
offset from the pixel grid in either direction, the result will be an
edge pixel whose color value can be computed exactly.
Cairo still rounds this wrong for color values >= 128 which is why we
use a dark gray that guarantees the resulting color values are all <128.
Add GSK_GPU_SKIP=glyph-align to turn off the glyph aligning.
FIXME: Should this be handled by the renderer at all or should we rely
on higher rendering layers to align glyphs properly?
This is kind of a tricky question just like with texture-scale nodes and
NEAREST filtering, because rendernodes can be embedded in other nodes
that disturb the pixel grid.
Transparency we need to support rounded corners. Client-side
shadows we need on platforms where the window manager does not
do them (mainly Wayland and X11). On platforms that support shadows
by default (macOS, Windows), we can just use them.
