What problem does this solve or what need does it fill?

The Mesh interface works with separate arrays of attributes, in an SoA fashion. GPU vertex buffers need packed vertices with all attributes, in an AoS fashion. This means the Mesh interface by design forces a costly repacking of data, even though the user might already have a proper GPU representation available.

In a custom project, building a mesh of cubes on a grid of 128^3, allocate_and_free_meshes() takes 150.8ms (Tracy), of which over 40% seems in write_packed_vertex_buffer_data() and about 30% in create_buffer() (VS profiler). Running in release with -C target-cpu=native.

What solution would you like?

• An interface with a way to provide packed attribute data already laid out correctly.
• An interface with a way to pre-allocate a buffer and reuse it, so that I can quickly switch between grid resolution for live preview without re-allocating a GPU buffer each time (only need to update the vertex data).

What alternative(s) have you considered?

Create a separate abstraction where I manage all wgpu objects manually, like Hanabi does. This feels terribly sad for a mesh buffer.

Additional context

Trying to make a live preview of some algorithm, and I need to modify a mesh dynamically each time the user makes a change in some parameters. Ideally this should be interactive; currently this runs at 0.25 FPS, and between half and 2/3rd of the time is lost in the Mesh interface (the remaining is on my CPU algorithm, which is being optimized and should slim down).