[Idea] Remember (partial) framebuffer state

[shermp]

Hi @NiLuJe , I'm baaack :D

I thought it would be great if one could show an image (or dialog box, or text...), and then when done, restore the original framebuffer state, so that the user isn't presented with the remnants of what we printed when we are done.

I was thinking perhaps it could be implemented as a 2 or three element stack, with each element saving the origin, dimensions, and raw scanlines of the region to be saved.

The user could then call a function like fbink_save_region() up to as many times until the stack is full. The could then restore the previous state with a function like fbink_restore_region(), again could be called multiple times until the stack is empty.

The main issue I see is memory usage, which is why the stack size would have to be fairly limited.

Thoughts?

[NiLuJe]

One obvious solution is flip buffers, which is usually totally doable on the target hardware... as long as bpp <= 16 :D.

So, moving on, because Kobos are 32bpp by default, there's the alt_buffer thingy in mxcfb calls that I've never played with, but whose use-case I'd imagine to be something like that?
(Or it might just be there to handle the shadow buffer directly? A very very very quick glance at the kernel makes me think this is still expected to be in the fb memory...).

---

So, yeah, doing it manually would seem to be the best way forward.

And, yeah, either a simple backup copy and save/restore calls, or a small stack w/ pop/push calls would seem the logical way to go ;).

Whether something like that has a place in FBInk, instead of in something a tiny bit higher-level is a valid concern, though...

Granted, this is probably easier done with access to the internal API ;).

---

As far as memory goes, at the expense of a bit of extra computing power, one could always store the data in the smallest pixel format possible (i.e., 8bpp) via img_convert_px_format, since we're probably not going to restore it in one go with a memcpy.

Which does raise another valid question: at the expense of memory usage, forgetting about the region/origin, and just storing the full visible fb area in the native pixel format would allow us to just memcpy it back & forth, which I'd imagine would be faster.

[NiLuJe]

This is just me thinking out loud, as I don't particularly have anything against the idea, and I think it can easily be done in a completely transparent manner for those who'll never have any use for it, without any performance or complexity hit.

PS: Welcome back ;).

[NiLuJe]

If I'm not completely terrible at maths, the full visible region of the fb on the H2O takes ~6MB @ 32bpp, which is still fairly tame as far as these things go ;).

[shermp]

Part of the idea of saving a region, instead of the entire fb, would be to allow partial e-ink refreshes, instead of doing a full refresh.

I guess an option would be to add a function to grab the region of the framebuffer one would be interested in, which could then be restored using the print_image function.

On the other hand, using memcpy is nice and simple :p

[NiLuJe]

Yeah, even regardless of anything else, a "region grab" public function seems like a moderately useful thing to have ;).

(I'm not helping, am I? :D)

[NiLuJe]

Oohkay, I'm back :).

Did you think about it some more? Leaning towards something in particular?

I'm inclined to go with a somewhat generic dump/restore approach, both for the full fb and for a region.
Basically memcpy the full fb or region line by line, (meaning we store it in the native fb format). memory would be allocated by the dump function, to be freed by the caller, because we're certain to do the maths right depending on bitdepth this way.
That keeps things somewhat separate from everything else, but it keeps the code relatively simple as it's basically a bunch of memcpy ;).

The rotation crap might be a tad annoying to handle, but that's it. The other usual suspect would be 4bpp support, but that shouldn't be too bad ;).

Haven't actually done anything yet, that's just my latest braindump ;).

[shermp]

Welcome back :)

I haven't actually thought about this much lately (I've managed to get myself stuck in shell script purgatory, in which my procrastination tendencies have shot WAAAAY up... can you help? :p ),

Your idea sounds good. Rotation sounds like it would be a pain. Perhaps the simplest option there would be to mark the dump as invalid if the rotation changes.

[NiLuJe]

Ooh, I hadn't even thought about a rotation switch between the dump and the restore (I was thinking of the usual pickel "hey, I'm in Landscape but you should actually use me in Portrait" crap). Yeah, ouch. :D.
Yeah, in that case, not doing something stupid with it seems the most sensible approach ;).

And yeah, I am familiar with the rabbit hole of shell scripting... :D.

[shermp]

Here's an even nastier thought that occurred to me in the shower.

How do you handle the situation when the the orientation is the same at dump and restore, BUT there was one or more rotation changes between them...?

[NiLuJe]

Well, that would at least restore properly and at the right coordinates ;).

I'm not sure I see a chain of events where that would be problematic?

[shermp]

After thinking about it a bit more, you're probably correct, it probably wouldn't be to much of an issue.

[NiLuJe]

Started working on this in the ctrlz branch ;).

Full dump/restore appear to be generally behaving in non-sneaky cases...
Regional support later tonight ;).

[NiLuJe]

Okay, regions done. Seems to behave on sane layouts, will have to test/fix corner-cases (like pickel rota & 4bpp) later ;).