Refactor epi::Frame

[emilk]

epi::Frame contains methods for controlling the surrounding app (i.e. the native winit window or the web browser). At the moment this includes allocating texture, quitting and changing the window size. We may soon also be able to toggle decorations, toggle fullscreen and request user attention.

At the moment Frame is only available in App::update which means you cannot call this methods from a separate thread.

I think it would be useful if we could change App::update (and App::setup) from taking a &Frame<'_> to taking a &Arc<Frame>. A user could clone this Arc and send to a background thread. This would allow users to e.g. start HTTP requests, and when finished request user attention, allocate a texture, or similar.

Perhaps we want something like struct FrameRef(Arc<Frame>) or FrameRef(Arc<Mutex<Frame>>) to encapsulate this in a nicer way (similar to egui::CtxRef vs egui::Context).

We could then replace the current repaint_signal with just a normal call (frame.request_repaint();, perhaps more appropriately named request_update).

[cessen]

Just want to drop a note here that I would find this especially useful with the applications I'm writing. I go out of my way to make sure that any long-running jobs aren't on the same thread as the GUI, but often these are jobs computing or updating raster images to display.

Currently I kind-of-sort-of work around this by having those long-running image processing jobs (taking tens of seconds in my case) mark the image as "ready" for a texture update when they're done, on a thread-safe bool variable. Then the GUI code checks that variable on every update, and transfers the image to a texture when true.

It works okay, since the long-running work happens on another thread. But even just transferring the image data to a texture takes a small bit of time (these are very high-res images) and makes the gui hiccup whenever it happens.

Being able to allocate textures from other threads would both simplify the code a lot and eliminate the hiccups.