eframe with wgpu panics when unloading texture in same frame as rendering it

[Rusty-Cube]

Describe the bug
When using eframe with the wgpu renderer the program may panic, if you drop a TextureHandle in the same frame as it is used for rendering. The panic happens when egui_wgpu::winit::Painter::paint_and_update_textures submits the wgpu::Queue in crates/egui-wgpu/src/winit.rs:688. The unloading of the texture happens before that in line 673. I barely understand any of the code in that function, but if I just move the texture unloading to after the queue submitting (e.g. line 693), my code doesn't crash anymore.
If this is the correct fix, this means that destroying a texture is not a queued command. I tried to find out about that, but only found:

• The documentation of Texture::destroy: "Destroy the associated native resources as soon as possible."
• This issue with associated PR which covers the topic of destroying buffers and textures, and may imply my above assumption.
  If this is not the correct fix, there may be a bug in wgpu itself.

To Reproduce
Steps to reproduce the behavior:

1. Run the following eframe program with the egui-wgpu feature enabled:

use eframe::{
    self,
    egui,
};

struct MyApp {}

impl eframe::App for MyApp {
    fn update(&mut self, context: &egui::Context, _frame: &mut eframe::Frame) {
        // load texture
        let texture = context.load_texture("my image", egui::ColorImage::example(), Default::default());

        // use texture
        egui::CentralPanel::default().show(context, |ui| {
            ui.image(egui::ImageSource::Texture((&texture).into()));
        });

        context.request_repaint();
        // texture is destroyed
    }
}

fn main() -> eframe::Result {
    let native_options = eframe::NativeOptions {
        renderer: eframe::Renderer::Wgpu,
        ..Default::default()
    };
    eframe::run_native("My App", native_options, Box::new(|_| Ok(Box::new(MyApp{}))))
}

2. See the panic with the following message:

Error in Queue::submit: Validation Error

Caused by:
  Texture with 'egui_texid_Managed(1)' label has been destroyed

Expected behavior
The example picture should be shown in a window and the code should not panic.

Additional context
I encountered this issue in a project in which I want to display the image files in a folder as described in #5200. Since I may not be able to hold all images in memory, I unload them regularly depending on the selection of the user. If I scroll through the images too quickly, the crash occurs.
In my project the crash happens quite randomly, but with the example program above I can reliably produce a panic on frame 1. I'm not sure if this will work on every machine though.

[lucasmerlin]

Hi! That definitely sounds like a bug. I assume, if you run the example code with the gl backend that it works successfully?

Moving the free_texture calls below the submit sounds like a reasonable fix, would you like to open a PR?

[Rusty-Cube]

The example runs just fine with egui-glow.

[nickd-airo]

Thanks for fixing this. I came across this issue in a different way. This issue was causing crashes that were also somehow related to the state of a grid. See attached for MWE if anyone else comes across this. This commit fixed my issue.
main.txt