Open emilk opened 2 months ago
Probably you shouldn't do that. Correct me if I'm wrong, but it seems there a battle of two opinions. When egui starts updating in background, someone complain why application consumes CPU when it hidden. Then egui stops updating in background and another people asks why his code didn't run when app not on the screen. It seems to me that there was a several iterations of this issue at the time present.
egui is a GUI library. The GUI code should not drive the application logic. Period. If you need other activities except GUI, create another thread and do it there as frequently as you want.
When egui starts updating in background, someone complain why application consumes CPU when it hidden.
It will only update if someone calls ctx.request_repaint
. With https://github.com/emilk/egui/issues/5113 it will also be free if nobody adds any logic to tick()
.
If you need other activities except GUI, create another thread and do it there as frequently as you want.
That's difficult on web (no easy access to threads). It also introduces the need for users to add locks to the data in their App
.
If the eframe web app is in hidden (e.g. is in a background tab in the browser), then any call to
request_repaint
will be ignored, and not result in a call toApp::update
.That's because eframe checks if
request_repaint
has been called fromrequestAnimationFrame
callback, which is not called if the application is hidden.Solution
If the web page is hidden, then calling
request_repaint
should schedule asetTimer(…)
callback to callApp::update()
(must done via a setTimer delay, or we could haveApp::update
callrequest_repaint
which in turn callsApp::update
.We also need some guards to make sure that multiple calls to
request_repaint
in a row only results in one call toApp::update
, for instance via this pseudo-code:Related