Slightly less crappy screenshot performance #1206
Conversation
Defer the actual copy to our usual blit methods And do that in a pixel format closest to the input format
This comment has been minimized.
This comment has been minimized.
|
Also squashed the crap fallback to RGB24 instead of RGBA32. We drop the alpha anyway, and we don't gain anything by pixels being pointer-aligned here, since we're doing byte by byte load/stores anyway. |
|
Thankfully, no-one should be using said crap fallback anyway, so BB8 & BB32 fbs (AKA. the sane ones) should enjoy significantly less crappy performance. |
|
Also benefits from the blitting fast-paths if applicable (i.e., type matches, and source is not rotated), and uses the C blitter if enabled. |
(And a fast-path is viable, i.e., no rotation, matching strides)
|
Actually unbroke it in !BB8 (wrong stride :s), and made it zero-copy if possible (which, granted, will be rare. Basically the same cases as the block copy blit, e.g., an unrotated Forma). |
Turned out to be massively slower (like, three times), for... reasons? Reading the fb memory is slow? Bad cache interactions with LodePNG's read patterns? Who knows.
|
And testing the zero-copy thingy on a Forma revealed that it was hilariously slower, because CPUs are weird, I guess? So I scrapped it ;). |
|
(Might add the proper ffiutil.strcoll stuff in this PR ? :) Just mentionning it because you're familiar with ffi and I don't want to have to do it, so ... :) |
|
Sure, I can do that ;). |
* Bump base koreader/koreader-base#1205 koreader/koreader-base#1206 koreader/koreader-base#1207 * The strcoll shenanigans have been moved to ffi/util
By using our existing blitting methods if possible, and outputting in a pixel-format as close to the input one as possible.
(LodePNG itself appears to have been smart enough to squash grayscale-as-RGBA32 to grayscale all on its own in the encoding stage, so, no space savings on the encoded files).
re: koreader/koreader#6736
This change is