Update sampler along with texture on wgpu backend

[valadaptive]

• Closes Partial texture updates will update the sampler in egui_glow but not egui_wgpu #5121
• I have followed the instructions in the PR template

This unifies the code paths in update_texture somewhat, so that the texture sampler and bind group are always replaced.

Not sure whether removing and reinserting the texture from and into the textures map, or creating a new bind group, has much of a performance impact. An alternative, as described in #5121, would be to split the functionality for updating a texture's data from updating its options, so that we don't have to unconditionally update the bind group (or do something like store the options to check if they're changed).

[Wumpf]

thanks for finding and fixing this!

Not sure whether removing and reinserting the texture from and into the textures map, or creating a new bind group, has much of a performance impact.

I'm not worried about removing and inserting the texture as this is a fairly fast operation. But re-creating the bind-group every time is indeed a bit worrisome to me since this is an extra resource that has to be taken care of by wgpu and the driver. (On the web this even needs to wait garbage collection if the old one isn't explicitly destroyed).

I figure solving this shouldn't be too hard: We just store something like this on the hashmap

struct Texture {
    /// The texture may be None if the `TextureId` is just a handle to a user-provided sampler.
    texture: Option<wgpu::Texture>,
    
    /// Bindgroup for the texture + sampler.
    bind_group: wgpu::BindGroup,
    
    /// Options describing the sampler used in the bind group.
    options: epaint::textures::TextureOptions,
}

and recreate/fetch sampler & recreate bindgroup only if the options have a mismatch.

Oh and while you're on it: let's call destroy if we discard a bind_group.
It doesn't make a difference on native, but right now wgpu doesn't call that for you on object death when being on WebGPU. This is relevant because all WebGPU objects live in Javascript land and thus get only destroyed once the garbage collector runs over them.
Same on free_texture for the texture and bindgroup. (calling destroy invalidates every wgpu object that uses the resource at that point and hasn't submitted its operations yet, but free_texture is &mut and render is &self, so we should be good!)

[valadaptive]

I've updated the code to store the TextureOptions along with the other texture info, and only update the bind group if they differ. I've kept the remove/reinsert from the map, since the borrow checker makes us choose between duplicating the code for creating a bind group or moving the data out of the map.

Oh and while you're on it: let's call destroy if we discard a bind_group. It doesn't make a difference on native, but right now wgpu doesn't call that for you on object death when being on WebGPU. This is relevant because all WebGPU objects live in Javascript land and thus get only destroyed once the garbage collector runs over them. Same on free_texture for the texture and bindgroup. (calling destroy invalidates every wgpu object that uses the resource at that point and hasn't submitted its operations yet, but free_texture is &mut and render is &self, so we should be good!)

I've also made it so that free_texture destroy()s the texture. As far as I can tell, BindGroup doesn't have a destroy method?

[Wumpf]

oh, interesting! Wasn't aware that BindGroup has no destroy.
Small nit on doc string otherwise good to go imho. Thanks for taking care of everything!