Queue::write_texture performance considerations

[eblack-leaf]

I am attempting to make an image gallery with winit + wgpu to be run in browser with wasm and have run into some problems with texture writing times.
I have around 60 images all less than 1400x1400 storing as Rgba8Unorm (I would like Rgba32Float but I reduced precision to help with speed). I have experimented with

• pre-loading a texture for each one, which results in massive stalling (up to 20 seconds or more).
• one "slot" texture at size 1400x1400 and Queue::write_texture when changing pictures to fill with the next image bytes (this is my current approach and only stalls minimally when changing)
• three "slots" that rotate out with previous / current / next (does that help with performance at all? my thought is that one texture is being used to write to and does not stall the one being read for rendering), but this means I have to write 2 extra textures each change to keep the rotation going rather than the one "slot" filled each time.

The project is foliage, and I use a single render pass that clears instead of load contents (I believe more efficient on tile-based gpus such as mobile?). Every other render pipeline I have made works amazingly and performant (most have small textures or none) so I feel it is not other factors that affect this.
I have profiled in Firefox and the only sections that even come close to noticeable time-spikes happen when I Queue::write_texture to change.

The last step in my architecture I can attempt is sending the Queue::submit + render-pass function to another thread (not the main window loop from winit) but I am having trouble refactoring to get to that point and would like some guidance on the most efficacious approach before attempting this part. I also feel it would not speed up the write_texture and only let me have control to the event-loop faster but still would be out of sync with what is visible.

I can provide more details if needed, but just would like anyone's opinion on the merits of each approach generically if that can be determined without code specifics (which I can happily distill to illustrate concepts). I see that the Do's and Don't s section talks about the memory allocator and to not create many textures per frame. I initially tried parsing out the creation over time (1 per second or so) but it just made it choppy each load so I abandoned that.