You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the progress bar draws the animation directly to the oled screen buffer.
This means it's impossible to store animation buffers and reduce draw calls as the buffer needs to be painted every time (because other pixels on the oled may have changed).
If we, instead, store a framebuffer only for the progress bar and blit it against the oled framebuffer we could cache the animation resulting in a much higher framerate (as all the animations are repeating), especially for progress bars which don't change their widths.
Currently the progress bar draws the animation directly to the oled screen buffer.
This means it's impossible to store animation buffers and reduce draw calls as the buffer needs to be painted every time (because other pixels on the oled may have changed).
If we, instead, store a framebuffer only for the progress bar and blit it against the oled framebuffer we could cache the animation resulting in a much higher framerate (as all the animations are repeating), especially for progress bars which don't change their widths.
https://docs.micropython.org/en/latest/library/framebuf.html#framebuf.FrameBuffer.blit
The text was updated successfully, but these errors were encountered: