Hold QR animation on brightness tips and reset animated QR sequence #495
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.
Depends on #494
This PR actually only has minimal changes; to get a proper diff you need to compare against https://github.com/kdmukai/seedsigner/tree/qr_encoding_refactor
Description
For fountain encoders, the first
n
frames are extremely valuable. But since we start the animated QR sequence with the brightness tip overlaid, many of the early frames will be wasted and/or unreadable.This change pauses the current frame whenever the brightness tip is visible and then restarts the animated QR sequence (per @jdlcdl's suggestion) when the brightness tip deactivates.
Fountain encoders: should be beneficial
"Simple" animated encoders (Specter xpub): doesn't really matter
Static encoders: no effect
This pull request is categorized as a:
Checklist
pytest
and made sure all unit tests pass before sumbitting the PRIf you modified or added functionality/workflow, did you add new unit tests?
If this evolves to support more elaborate changes to the fountain encoder sequence, then dedicated tests will be added.
I have tested this PR on the following platforms/os:
Note: Keep your changes limited in scope; if you uncover other issues or improvements along the way, ideally submit those as a separate PR. The more complicated the PR the harder to review, test, and merge.