Was looking for something else and ran across an old example.
Modified it to show the issue.
function setup()
pc = 1 -- print counter
fc = 0 -- frame counter
printw()
displayMode(FULLSCREEN)
printw()
d = true
dd = true
end
function draw()
fc = fc + 1
if d then
printw()
background(0, 0, 0)
printw()
displayMode(STANDARD)
printw()
d = false
elseif dd then
printw()
dd = false
end
if fc < 10 then
printw()
end
end
function printw()
print(fc,pc,WIDTH)
pc = pc + 1
end
Maybe it’s not so much a bug as a way to tell when the window has fully changed.
I think this is related to it sliding out all cool (take a frame to do so) instead of a blinding snap.
Yes - it appears Codea continues to call draw() asynchronously.
Here’s what’s even weirder to me - your “if d then” block does printw() 3 times - Yet we see fc=0 twice, and fc=1 4 times. That means the actual execution sequence is "codea wakes up, enters the ‘if d then’ block, printw() twice, then runs displayMode(STANDARD) - and a new draw() starts, increments fc, and the rest of the “if d then” block runs (and another printw() fires), then the second draw() terminates).
makes me wonder - are draw()s running in parallel? It seems so, or maybe the first is just interrupted for the 2nd, and is then resumed? Certainly unexpected behavior - I’d expect draw() to finish out before it’s called again.
The display width doesn’t actually change until the sidebar is completely off (or on) the screen. It only stretches the canvas while the draw loop is running, and then sets the new width once it allocates a new OpenGL frame buffer.
The width and height should always represent the actual frame buffer size - even if it’s being temporarily stretched or squashed to animate the sidebar in or out.