Conversation
Custom sleep images with greyscale could take ~60s because drawBitmap ran for the BW compose and again for each grey plane. Stream LSB/MSB strips during a single SD read and add SleepActivity phase logging to diagnose sleep entry.
When a custom sleep image exceeds the screen, sample from the output grid instead of walking every source pixel. Keeps the single-pass grey decode and deferred strip flush.
Large custom/cover greyscale BMPs OOM when LSB/MSB strips from
drawGreyscaleBitmapForSleep are batched in RAM. Add ISleepGreyStripSink
and SleepGreyscaleStreamWriter to write strips to /.crosspoint/sleep_cache
({hash}.raw, .lsb.raw, .msb.raw) as the BMP is decoded, then flush them
back in bounded 80-row reads for the grey e-ink refresh. Add loadGreyscale
and cache-hit paths for cover, custom, and stats sleep screens so repeat
sleeps skip the ~20s decode. Keep SleepGreyStripBatch as a memory fallback
only when no source path is available.
Sleep screen cover crop mode skipped every row for standard bottom-up BMPs because crop bounds and screen Y were computed from file row index instead of image row-from-top.
Closed
kinland
changed the title
Author
|
Worth noting (as I did on the clock PR) that I've gone through at least 100 sleep cycles with the improvements in the PR and not noticed any new issues, battery drain, etc. |
Author
|
Would it help get this merged if I split this into smaller PRs instead of one 760 line PR?
|
kinland
force-pushed
the
fix/sleep-screen
branch
from
July 29, 2026 00:38
affdd5f to
37f9986
Compare
Loading grey planes before displayGrayscaleBase set lsbValid and forced a clean-base path that wiped controller RAM, so cache hits skipped greyscale entirely.
Avoid allocating a full ~52KB grey plane on cache hit; read LSB/MSB from SD in bounded strips and write them with writeGrayscalePlaneStrip after the BW base refresh.
Forward-only strip flushing dropped grey pixels when phyY decreased under Portrait, leaving only the left ~9% band. Accumulate full planes when RAM allows, otherwise reload strips in any order, and bump the sleep cache format version.
Dual-plane stream encode needed ~104KB contiguous RAM, routinely OOMed, aborted partial cache writes, and forced a slow cold overlay every sleep. Snapshot BW/LSB/MSB from the overlay path instead so sleep_cache populates and later sleeps can hit the strip apply path.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
I was having two problems on my X3 that this branch addresses:
Sleep Screen Cover Modewas set tocrop, the sleep screen was blank (bug Sleep screen 'Cover + Custom' broken in recent builds #15 )Additional Context
The crop fix: Sleep screen cover crop mode skipped every row for standard bottom-up BMPs because crop bounds and screen Y were computed from file row index instead of image row-from-top. Now uses crop bottom-up BMPs using row-from-top mapping
AI Usage
While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it
helps set the right context for reviewers.
Did you use AI tools to help write this code? YES