Background loading of changing images

[Rusty-Cube]

I'm trying to build an application for displaying the image files in a folder using eframe. It should provide a way to quickly navigate through the images, displaying one image at a time (for now). If I use egui_extras::install_image_loaders and a single egui::UI::image with changing URI strings per update, it takes some time for the image to load, during which the window is even unresponsive (the loading animation is also stuck). Since the image that is to be displayed next is somewhat predictable, I'd like it to be loaded in advance. The whole loading procedure should also happen in the background, so the UI always stays responsive.
It also seems like all the image data stays in memory indefinitely. After displaying a lot of images the application got killed automatically for using up too much RAM. Images should be unloaded at some point, so the amount of memory used stays reasonable.
So I tried to manage the image data myself. I wrote a worker thread that (preemptively) loads the images from the disk, calls egui::Context::load_texture with the image data and then egui::Context::request_repaint, if the image wasn't loaded already during the last repaint. The main thread would get the epaint::TextureHandle, which the worker thread produced, and use that in the call to egui::UI::image.
This seems to lower the time between image changes a bit, but there is still some delay every second image. I guess, I masked the disk access time, but the upload to the GPU is still noticeable. Profiling suggests, that the upload takes place in egui_glow::painter::Painter::paint_and_update_textures in the main thread, while egui::Context::load_texture in the worker thread only queues the upload in epaint::textures::TextureManager::alloc.
So my way of using a worker thread doesn't quite get me there and is also probably not how it's intended to be done with egui anyway. I'm wondering if there is a nice way to achieve my goal. I read somewhere that multithreading with OpenGL is tricky. So maybe it's not possible at all? Do I need Vulkan? What about async/.await?

[lucasmerlin]

I'm using wgpu where it's relatively easy to upload images from another thread, so if you don't rely on opengl in some other way you could try switching to wgpu (with eframe it's as simple as turning off default features and turning on the wgpu feature).
You can then use Renderer::register_native_texture to register the texture with egui.
Or you could write a custom texture loader that basically does the same thing (which is what I'm doing).

I plan on open sourcing my texture loader (which is also much more efficient at loading textures in wasm, relying on the browser to decode them) at some point but I haven't gotten to that yet.

[Rusty-Cube]

If I just enable the wgpu renderer, I don't notice any delay between image changes anymore, even though from my understanding the texture uploading should still happen in the main thread. But if I change images too quickly, it crashes due to missing textures ("Texture with 'egui_texid_Managed(33)' label has been destroyed"). I guess it tries to display textures, which the worker thread already unloaded.
The main thread always holds a TextureHandle of the currently drawn image in the app's update method, so I thought it should be fine. As I understand it, even if the TextureHandle in the update method is the last remaining one, the actual freeing would only occur after rendering in egui_wgpu::winit::Painter::paint_and_update_textures:662.
Not sure, what I'm missing here. The fact that it doesn't crash with glow but blows up the memory instead hints that glow doesn't actually unload the textures if all TextureHandles are dropped. Here's the relevant snipped from my update method:

egui::CentralPanel::default().show(context, |ui| {
    if let Some(file_index) = self.file_index {
        let file_name = &self.file_names[file_index];
        let texture: Option<egui::TextureHandle> = self.image_loader.get(file_name, SizeKind::Full);
        if let Some(ref texture) = texture {
            ui.add_sized(ui.available_size(),
                egui::Image::new(egui::ImageSource::Texture(texture.into()))
                .max_size(ui.available_size()),
            );
        }
    }
});

What does the use of register_native_texture that you suggest imply? I probably wouldn't call Context::load_texture and circumvent epaint's TextureManager, so the image_delta in paint_and_update_textures is always empty? How do I make sure, the texture is always available during rendering if I don't use the image_delta? I guess I could just keep it alive until the next call to App::update and drop it, if I won't put it into the image widget again?

[Rusty-Cube]

Even though I still have open questions, just using wgpu does it for me. The speed is sufficient and the crash fixed. So I'm marking your comment as the answer.