notcurses_refresh() clears but does not restore graphics

[dankamongmen]

In both kitty and sixel/iterm, notcurses_refresh() clears all bitmaps, but they're not redrawn. This is very bad especially in Kitty, since moves no longer work (sixel always redraws, so you eventually get your bitmap back). I'm thinking notcurses_refresh() needs to mark all visible graphics SPRIXEL_INVALIDATED prior to the clear, so rasterization picks them back up, much as we do when transitioning to a new pile. It's not the biggest deal in the world, but it ought get fixed.

[dankamongmen]

in fact, maybe the easiest way to do this is simply to reset last_pile?

[dankamongmen]

in fact, maybe the easiest way to do this is simply to reset last_pile?

this does not appear to work with at least kitty, which makes me wonder if switching piles works properly there at all...?

[dankamongmen]

how was i testing this?

[dankamongmen]

hrmmm. how do we intend to do this with modern kitty? the whole point of reflection was to avoid keeping a copy around =[. well, and also to avoid the bandwidth for restores, but ugh, i don't want to keep a copy! are we actually doing a clear? i'm pretty sure we are =[.

[dankamongmen]

so far as i can tell, this does happen with sixel, but it does not happen with kitty, since the kitty graphics are not cleared in notcurses_refresh() (maybe they once were)?

to test, i'm running ncplayer -bpixel ../data/worldmap.png. at "press space to continue", ctrl+L clears the screen (save for text), as this bug suggests. with kitty, there is no change. i think kitty graphics aren't deleted? yes....it looks like our clear gets eaten in notcurses_refresh(), argh! (raster_and_write() calls fbuf_reset() as its first task, whoops)...yeah, with that fixed up, kitty graphics now also disappear with this test.

[dankamongmen]

well right now it's almost impossible, because we feed a local ncpile, which has no sprixels attached to it. this ties into the problem with [xray] right now where we see sprixels from both piles at once. there we need explicitly kill the one which moves off-pile...somehow. this would be handled for us in clean_sprixels if we somehow moved the off-pile sprixel into the active sprixelcache...but we'd need move it back to the other pile, invalidating thread safety requirements. hrm (this doesn't happen in [xray] on sixel because we're scrubbing the old area, but it would happen elsewhere)!

[dankamongmen]

it's going to be very difficult to do this independently of the user so long as they're big bitmaps. this is yet another thing that mosaics would make trivial. let's not spend time on this when mosaics will get it.