Canvas method to request a new draw

[almarklein]

Having a (cross-gui-toolkit) method that can be used to request a new draw would be nice. When using qt canvas.update() does the trick, but a more general solution would be favorable, plus we can add some niceties:

• calling window.requestAnimationFrame schedules a draw call indirectly (non-blocking)
• animation is paused when the canvas is not visible (scheduled calls are not executed until canvas becomes visible again)
• refresh rate of the GUI environment is matched if possible
• callback is passed the time delta since the last call
• you have to request another draw at the end of your animation function; this avoids scheduling too many calls if your drawing happens to be slower than the time budget allows for

[Korijn]

I'm wondering if we should just leave this up to the application developer by providing an API that allows them to do it.

[Korijn]

Nice work on the docs! The GUI API page's examples left me a little confused though; where are the calls to request_draw?

Looking at the Qt canvas a little better, it appears that Qt is making the calls, rather than the python code. I guess my expectations were somewhat different here.

I understand that Qt will trigger a draw when the window is resized for example, or opened for the first time. Does Qt also continuously trigger drawing when there is no interaction, or does the user then need to use request_draw to achieve that?

[almarklein]

Good question. The GUI toolkit will indeed request a new draw when it knows that the visualization needs to be refreshed. Like when the window is resized, and om some systems when part of the window was hidden by another window and is now shown again. This was already the case before #78. What was added was the possibility for the user to request a draw. E.g. in cases that the visualization itself has changed.

This works somewhat different for Qt and glfw. In Qt the former already works automatically, and requesting a draw is done simply by calling update(). In both cases this will at some point result in a draw event.

For glfw you have to bring your own event loop. So this draw event ... we have to do that ourselves. The simplest way I could find to realize this is by adding a single function (update_glfw_canvasses) that you call on each iteration, and which draws any windows that have requested (manually or via e.g. a resize) to be redrawn.

In both cases, the window will not be redrawn continuously, unless you keep requesting redraws.

[Korijn]

Ok, great, that's perfect!

Qt the former already works automatically, and requesting a draw is done simply by calling update(). In both cases this will at some point result in a draw event.

Just to make sure I fully understand the details here: so Qt does not continuously call update() when only the visualization changes? Meaning that the user needs to call request_draw().

[almarklein]

Haha, now I'm not sure if I understand your question correctly :)

So, indeed Qt by itself only generates a new draw event when the window is somehow invalid (e.g. on resize). This means that our users need to call request_draw() when the viz needs an update. The request_draw() function for the Qt canvas simply calls .update().

(In theory our users could just as well call update(), except that request_draw() is the generic function that also works on the glfw canvas.)

[Korijn]

Got it! Thanks