dos authored 1 year ago and dos committed 1 year ago

Closes #148

dos authored 1 year ago and dos committed 1 year ago

\o/

dos authored 1 year ago and pippin committed 1 year ago

Mode switching interacts weirdly with overlay drawing. Overlays
are rendered in-process, while mode change still occurs in the
graphics task. Make sure that we don't end up with framebuffer
getting cleared after rendering by queuing a few more frames
to render and flushing the whole pipeline.

dos authored 1 year ago and pippin committed 1 year ago

Our fork has bumped the priority up by one, but it failed to also
adjust the priorities of other tasks that may get spawned by
micropython (such as RMT, I2S or _thread). The change seems to have
been made to make its priority higher than the graphics task's, but
the graphics task is pinned to another core these days (the blit task
remains unpinned at priority 2).

Change the mp_task's priority back to the one used by upstream.

dos authored 1 year ago and dos committed 1 year ago

Because why not.

Also, only do 2x rendering at zoom>=0.9 and when not paused.

zoom which controls relative video-size to screen and cx and cy
which determine the position of screen video gets rendered to,
defaults zoom=1.0, cx=0 and cy=0

The yuv420 fragment provider in ctx is only nearest neighbor - flickering
between the two when changin between color/gray segments of a video is
less consistent than sticking with one rendering mode.

Reduces graphical glitches on mode switch.

The context relies on mode-dependent initialization. Changing
the mode mid-frame results in rendering glitches.

dos authored 1 year ago and pippin committed 1 year ago

A simple transition with no animation.