Menu drawing speed optimizations #36
Open
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.
Hi!
This is my attempt at optimizing the main menu drawing speed.
The slow speed was not ideal for the user experience, but I also noticed cases where the gcode sender on a PC (UGS) would stutter when jogging with the keyboard while the pendant was on the main menu. It took me a while to figure out it was the problem, but whenever I would put the pendant on any other scene I would not experience that problem. To solve this issue initially (and I think permanently in my case) I've disabled the flow control.
I figured out what was slow was the real time opening and decoding of menu button PNGs.
I optimized it by caching those button images in sprites so that it is only done once.
I tested 2 variants of this approach, but memory constrains forced me to use my first version (v1) that uses a lower sprite blending quality, resulting in a need for new png buttons images that use 2 level of transparency rather than 256, since sprite drawing only support key color transparency.
Overall this optimization makes the main menu navigation very snappy, I think it's a great improvement!
Try it out and make sure you update the new file system image as well.
I've currently left the "v2" in comment so it can be tried manually. The v2 would not require new png images, but unfortunately it causes memory issues it seems because of the 3 sprite buffers needed for each button state. In some cases other image resources would not load in other scenes.
A final note that I've only tested this on the CYD pendant with capacitive touch screen and physical buttons (although I also have the m5dial, but didn't have the time to test that one).