improved file manager speed (for t-embed usually)#2205
Open
mokapi47 wants to merge 1 commit intoBruceDevices:devfrom
Open
improved file manager speed (for t-embed usually)#2205mokapi47 wants to merge 1 commit intoBruceDevices:devfrom
mokapi47 wants to merge 1 commit intoBruceDevices:devfrom
Conversation
bmorcelli
reviewed
Feb 23, 2026
Comment on lines
-756
to
+753
| RfCodes data{}; | ||
|
|
||
| if (readSubFile(&fs, filepath, data)) | ||
| txSubFile(data); | ||
| txSubFile(&fs, filepath); |
Member
There was a problem hiding this comment.
This function has changed, and your PR is moving back to the old code.
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
2 participants
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.
On devices with a scroll wheel, like the t-embed, the file manager was quite slow for scrolling and hadn't been optimized for devices that can send a lot of requests in quick succession. So I improved it:
It redraws all lines with each scroll, so each redraw takes too long, and events accumulate. The solution: partial redraw (only 3 lines) for normal scrolling + full redraw only if the page changes. Fast redraw = we can process each event immediately without lag or teleportation.
Maximum 3 steps per event, but stops early if the scroll wheel stops spinning — so 1 slow click = 1 step, fast spin = up to 3 steps per frame.
If you really overuse the scroll wheel, of course it's going to start lagging... it's an ESP32, don't ask too much !