display_data does not yet have a way to save the state of the screen so that it comes up once the context is returned to.
Reproducing:
Switch to devel branch
Go to the 2048 game
Switch to Zeromenu (click PROG2)
Exit ZeroMenu (KEY_LEFT or click Back)
Result:
The 2048 game screen (that uses display_data) will not appear unless some other key is pressed. This is because, if display_data is used, the resulting image is not saved in the OutputProxy object.
Possible solutions:
re-implement the display_data rendering logic from the driver in OutputProxy, maybe using Canvas (alternatively, just copy-paste the implementation that uses luma.oled.
would work properly
code duplication
unnecessarily tying luma canvas or Canvas into the output subsystem
split the display_data rendering code into a (static) method that would return a PIL.Image, then get that method into OutputDevice and proxy it into OutputProxy
this method needs to be always available
side-effects are not sufficient - some other logic needs to be used, since the rendering method needs to be available regardless of whether context is the one active
display_data
does not yet have a way to save the state of the screen so that it comes up once the context is returned to.Reproducing:
devel
branchResult:
The 2048 game screen (that uses
display_data
) will not appear unless some other key is pressed. This is because, ifdisplay_data
is used, the resulting image is not saved in theOutputProxy
object.Possible solutions:
display_data
rendering logic from the driver inOutputProxy
, maybe usingCanvas
(alternatively, just copy-paste the implementation that usesluma.oled
.luma
canvas orCanvas
into the output subsystemdisplay_data
rendering code into a (static) method that would return a PIL.Image, then get that method intoOutputDevice
and proxy it intoOutputProxy