browser rendering method can cover up button effects

[qiemem]

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.

[TheBizzle]

Link the model?

[qiemem]

Woops: https://gist.githubusercontent.com/qiemem/1269f29077ee979b3f97/raw/24efd883ed0b159855bb62257eef21cd704e4d23/flashing-turtles.nlogo

[qiemem]

Possible fix: cancel and re-request the animation frame from button presses to bump it from the queue. Not sure if it would work, it would likely be up to browser implementation, and it's really pretty gross. I don't like this solution, but if this becomes a serious problem, it might be worth trying.