Update wgpu to 0.6 in iced_wgpu

[hecrj]

Updates iced_wgpu to use the latest release of wgpu 🎉

The new release of wgpu features a new StagingBelt type that we can leverage to reduce reallocations of staging buffers. As a consequence, we no longer pin gfx-memory to an old version and, therefore, iced_wgpu should no longer leak video memory!

The integration example has also been updated accordingly.

Fixes #438 and closes #486.

[kvark]

Did you consider write_buffer/write_texture instead of the staging belt?

[hecrj]

@kvark Hey, thanks for the review!

Did you consider write_buffer/write_texture instead of the staging belt?

Yes, but we are kind of stuck with a StagingBelt and multiple render passes until we can lift some limitations in wgpu_glyph (see hecrj/wgpu_glyph#46). Once those are dealt with, we will change the architecture to upload everything upfront and record all the draw calls in a single render pass.

While we could partially use write_buffer/write_texture right now, I think it's better to batch all the work once a full transition is possible. I plan to work on this very soon. This is just the first step!

[PolyMeilex]

Great work, I updated my project to wgpu 6.0 and new iced and did some initial tests and everything works as expected so far 👌

But I have to say that as a user that integrates iced into existing wgpu project StagingBelt is quite annoying, I have to keep track of belt that I don't even use and I don't think I need one in my engine (as it is a quite simple one) I have to add it into my abstractions solely for use in wgpu_glyph and iced.
tldr: I'm glad you're considering to move away from StagingBelt in future, and I just wanted to voice my opinion 😃

[dhardy]

I agree with @PolyMeilex; still at least in KAS (kas-gui/kas#121) the StagingBelt doesn't leak into any of the examples, so it is less of an impact.

[hecrj]

I'm glad you're considering to move away from StagingBelt in future, and I just wanted to voice my opinion

Once we can get rid of the StagingBelt, we should be able to also follow the middleware pattern.

still at least in KAS (kas-gui/kas#121) the StagingBelt doesn't leak into any of the examples, so it is less of an impact.

Glad to know! It doesn't leak into any of the iced examples either. iced_wgpu is the only subcrate directly leaking it, given that the user should be able to choose the chunk size.

[valpackett]

grrr, another local futures executor, breaking my GLib based project again >_< patched to spawn on GLib for now. Hopefully the "move away from StagingBelt" would delete the executor.