search

NiLuJe / FBInk

FrameBuffer eInker, a small tool & library to print text & images to an eInk Linux framebuffer
https://www.mobileread.com/forums/showthread.php?t=299110
GNU General Public License v3.0
315 stars 23 forks source link

Dump & Restore feature #33

Closed NiLuJe closed 5 years ago

NiLuJe commented 5 years ago

Basically, what was discussed in #31 (fix #31) ;).

Adds three new API calls: fbink_dump, which dumps the full screen fbink_region_dump, which dumps a specific region of the screen, supporting all the same crazy positioning options of the image printing code. fbink_restore, which restores those two kinds of dumps, in the exact same coordinates they were taken from, and errors out if it can't (bitdepth or rotation mismatch between dump & restore time).

This requires a new struct: FBInkDump, which holds a pointer to the FBInk-allocated storage, and the metadata it needs for the safety checks (i.e., coordinates, size, rota, bpp, is it full-screen). Needs to be zero-initialized, and free'ing is left to the caller. Don't leave the data pointer dangling, otherwise the _dump functions will try to recycle the struct by freeing the data! This means creating a single struct and keeping it around is perfectly valid, but it will only ever hold a single set of data, that from the latest dump call on it.

NiLuJe commented 5 years ago

Includes a stupid regression fix for Legacy Kindles, and a fast-path when blitting 8bpp images on an 8bpp fb.

Stupid test app for the feature available in utils/dump.c ;) (make dump).

NiLuJe commented 5 years ago

It appears to be handling the usual rotation trickeries, as well as 4bpp fbs.

All in all, that went fairly smoothly, but then, I'm fresh from the same kind of stuff in https://github.com/koreader/koreader-base/pull/878 ;).

NiLuJe commented 5 years ago

This pull request introduces 6 alerts when merging 3d821f7e2551f62c9d03cafdae7259b01b5cf809 into 18ec76f33982d6b918e0c2fda8828a64d471be10 - view on LGTM.com

new alerts:

Comment posted by LGTM.com

NiLuJe commented 5 years ago

Up next: I added a size field to the struct, which, besides allowing more safety checks, in the unlikely event the framebuffer memory shrunk (yeah, that should never happen :D), allows one to use it as input for fbink_print_raw_data, in the (also unlikely :D) event you'd want to do that...

I updated the test app with a fairly stupid example for this: taking a region dump @ 32bpp, and restoring it via fbink_print_raw_data @ 8bpp, but inverted. A slightly less tortuous use case would be simply restoring it at different coordinates, for instance.

(NOTE: While fbink_print_raw_data handles most sensible pixel format conversions, like the RGB32 -> Y8 done here, it doesn't handle all of them (mainly to/from RGB565 or from/to a 4bpp fb), and it doesn't handle rotating an image buffer at all, so, this is not a magic wand ;)).