New update_mode 'auto'?

[almarklein]

With #188 in mind, I got the idea that we could have an 'auto' update mode, that would be like 'ondemand', but would automatically issue a new draw for most incoming events, but e.g. for pointer_move only when a button is held down. This would mean that any application that does not have stuff that changes by itself---i.e. things only change in reaction to events---it just works.

I can imagine that people use 'continuous' to avoid problem when forgetting a request_draw() somewhere. With 'auto' this would be less of a problem, sparing battery live for possibly a lot of people :)

A possible downside is that the use of request_draw() may become less common, and less known.

Possible documentation could be:

• use 'ondemand' for full control when drawing happens; use request_draw() when needed.
• use 'auto' when your rendering only changes in reaction to events. You can still use request_draw when needed (e.g. short-lived animations).
• use 'continuous' when you want to draw continuously, e.g. when you have animations.
• use 'fastest' when you don't care about battery life and want the FPS to be as high as possible.

cc @Korijn

edit: fixed 'on_demand'->'ondemand'

[hmaarrfk]

Pointer move when mouse is up is required to get hovering effects.

[Korijn]

Yeah I mean the implementation would still just be on_demand with some extra calls to request_draw in interaction layers right?

[Vipitis]

sounds to me like it's doing on_demand with a request_draw during most events? perhaps it could be an example with capturing all events. Or an option in pygfx.
I feel like there is already a lot of combinations with vsync on/off and then fastest versus continuous and max fps smaller or larger than vsync monitor limit etc.
I already run into race conditions and it's tough to see through the event loop easily.

[almarklein]

Yeah I mean the implementation would still just be on_demand with some extra calls to request_draw in interaction layers right?

Yes, it's like 'ondemand' but with many cases a draw is requested automatically.

Pointer move when mouse is up is required to get hovering effects.

Yeah, so "when your rendering only changes in reaction to events" is not fully true ...

I'm feeling less enthusiastic about this idea today. If we could clearly (with a one-liner) explain in what cases a draw is requested automatically, it could work, but it's nearly all events, which sucks.

[almarklein]

Another idea could be to have a flag on the event object that handlers could set to indicate that they changed something that'd require a new draw. So code could event['request_draw'] = True instead of canvas.request_draw(). The advantage is that handlers don't need to have access to the canvas object to be able to request a new draw.

[Korijn]

There's also some "interesting" edge-cases to consider here like camera easing, where the camera is still moving a bit after user input has ended.