> This is the event distribution loop we use in our ocempgui-based projet:
> while renderer.distribute_events(pygame.event.wait()):
> pygame.event.wait() offers the advantage to return when (and only when)
> a new event is available, whereas pygame.event.get() returns immediately
> (mostly None).
Basically it is a full blocking call, which might lock user code thus forcing
a developer to use a full event driven design and implementation approach.
> The pygame.event.wait() approach consumes as few CPU time as possible as
> it is based on thread synchronization mechanisms provided by the host
> operating system.
> I'm not sure, but the existing pygame.event.get() approach seems to be
> designed to allow tuning such as FPS. There is a polling which is not
> that much CPU time friendly.
Right. It is a FPS based implementation. The friendlyness of course depends
on the timer settings the developer chooses.
> It would be nice to integrate such a loop either:
> * In replacement of the existing Renderer._loop() method (if
> internal timer no longer required).
And thus forcing a fully event driven apporach. Applications and games, which
change e.g. colours (floating gradient effecs, etc.) are lost with that except
using the SIG_TICK event or something else to allow constant updates.
In other cases they can stick with the usual update processes.
> * In combination of the existing Renderer._loop() method (if
> internal timer still required).
Sounds superflous to me, because it would not offer any new feature but instead
overcomplicate the loop.
> * As an alternative Renderer._loop() method - say
That might be interesting - at least for fully event driven applications and
Although I do not see any bigger difference in CPU usage by using either of
those approaches (timer + .get() vs. .wait()), mainly because of the 10ms
SIG_TICK distribution it might be an interesting option anyways. Do you have
any real example code, where OcempGUIs behaviour differs that much?