browser rendering method can cover up button effects

To reproduce, open up this model in Tortoise and NetLogo. setup, go, and then hit the crt num-turtles... button over and over. In NetLogo, you'll see turtles pop up briefly and disappear. Not so in Tortoise.

My first thought here was frame skipping. However, button presses trigger redraws, and when you disable frame skipping altogether, the problem persists.

After experimenting, I'm pretty sure what's happening is that the browser is drawing everything to a back buffer and then only flips buffers every so often. The go loop uses requestAnimationFrame, which queues a repaint and sets up the callback to trigger right before the repaint occurs (the callback being forever buttons and redrawing) right before the browser repaints. I think what's happening is that, when the button is pressed, another repaint has already been queued with the go loop callback set to come before. So, the button draws the turtles to the back buffer, but then before it renders to the display, the go loop runs, running go on top of it, clearing the turtles and overwriting the back buffer. Then the display updates. Indeed, when you set the speed slider way down, you can get the turtles to show up. This is because the forever loop skips calling go at slow speeds.

Honestly, I'm not sure this is actually fixable. It would be fixable if we could control the buffering behavior ourselves. That said, not sure if it would really be worth it even if it were possible.

Start by tracing the browser rendering path around the go loop, requestAnimationFrame, forever buttons, and redraws. Reproduce the issue with setup, go, and repeated crt num-turtles button presses, then compare behavior with frame skipping disabled and the speed slider lowered. Done means determining whether the button-drawn turtles can remain visible before the next go redraw.