diff options
| author | user <user@clank> | 2026-09-07 15:54:34 +0200 |
|---|---|---|
| committer | user <user@clank> | 2026-09-07 15:54:34 +0200 |
| commit | 2a440fbc01c4e4afd58e15ace5eddd4a171d15ef (patch) | |
| tree | 06cef911eca321ea6b00ed8aabc91b5242077e10 /src/app_draw.c | |
| parent | Merge branch 'graphics-fixes' (PR #2 from iksteen): five fixes to the kitty p... (diff) | |
| download | slosh-2a440fbc01c4e4afd58e15ace5eddd4a171d15ef.tar.gz slosh-2a440fbc01c4e4afd58e15ace5eddd4a171d15ef.tar.xz slosh-2a440fbc01c4e4afd58e15ace5eddd4a171d15ef.zip | |
graphics: a retransmit invalidates every placement of the image
Replacing an image's pixels deletes all of its placements on the
client -- kitty drops them when the data is replaced, which is the very
fact the place-once logic leans on. But the invalidation rode a local
in one gfx_place() call, so only the placement said in the same breath
as the transmit was owed again. The image's other placements -- a
second one elsewhere, the other pieces of one a float has cut -- were
judged unchanged against a client that no longer holds them, and
stayed unsaid: a picture the client deleted and we believe it still
has, gone until something moves it.
Masked before place-once by the every-frame re-emission, so this is
the regression that fix bought. The transmit now un-marks every
placement of its image, and each is said again as its gfx_place()
comes around.
The live check drives one image placed twice, then replaces its
pixels and places both again: both must reach the client after the
second transmit, where the old code re-sent one.
Diffstat (limited to 'src/app_draw.c')
0 files changed, 0 insertions, 0 deletions
