E-Ink: additional conditions for "Dynamic Partial" mode #3256
Conversation
This file contains 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
todd-herbert
force-pushed
the
dynamic-partial
branch
from
ed1642f
to
9060674
Compare
thebentern
approved these changes
Feb 21, 2024
markbirss
approved these changes
Feb 21, 2024
markbirss
reviewed
Feb 21, 2024
There was a problem hiding this comment.
quite neat to count the amount of black pixels
thebentern
added a commit
to meshtastic/artifacts
that referenced
this pull request
Feb 21, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Purpose
Offer more tools for "dynamic partial" code to find the best balance of full-refresh and partial-refresh.
Lay groundwork for imminent pull-requests (Wireless Paper v1.1, sleep screens).
Why
When using partial-refresh, some E-Ink displays struggle to "erase" black pixels - to change an existing black pixel back to white. Rather than returning to white, these "erased" pixels can remain a light shade of gray. This is seen as "ghosting" - a faint version of the previous image remains visible.
The prevalence of this effect varies from display to display.
While working to implement partial-refresh for Heltec Wireless Paper V1.1, it has become clear that "ghosting" is somewhat more of an issue than with the V1.0 board.
What the pull-request implements
Two new "dynamic partial" controls are proposed here:
EINK_PARTIAL_ERASURE_LIMITOnly active if defined in
variant.h. Attempts to track the amount of "erased pixels" since last full-refresh. When this amount eventually exceedsEINK_PARTIAL_ERASURE_LIMIT, ghosting is considered likely to be noticeable, and a full-refresh is forced.The tracking of "erased pixels" is an approximation, by comparing total black pixel count from image to image. Theoretically, an accurate number could be achieved by comparing image buffers pixel-to-pixel, but this would be more intrusive to implement.
demandFullRefresh()Public method, suitable to call from a
FrameCallback. Single shot, specifies that the next update is cosmetic (splash screens?), and must be drawn with full-refresh, to maximize image quality. No calls todemandFullRefresh()are proposed in this specific pull-requestPerformance
Overhead for entire "dynamic partial" code (incl. proposed changes):
LOG_DEBUG()calls)*Benchmarked on Heltec Wireless Paper
Supporting Media
Demonstration of
EINK_PARTIAL_ERASURE_LIMITHighlights a scenario where "erasure limit" applies
EINK_PARTIAL_ERASURE_LIMIT.mp4
Flow Diagram for
determineRefreshMode()This section edited to correct error in diagram.
