Delay in width update for display mode change

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



0	1	750
0	2	1024
1	3	1024
1	4	1024
1	5	1024
1	6	1024
2	7	1024
2	8	1024
3	9	1024
4	10	750
5	11	750
6	12	750
7	13	750
8	14	750
9	15	750

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.

It’s a weird loop but I was trying to pin things down



2 0s in setup
3 1s for d
1 1 for  fc lt 10
1 2 for dd
1 2 for fc lt 10

3 and after are all fc lt 10


I could have marked them better/give them names in the print :slight_smile:

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.