Reuse a dynamic buffer for different draw calls

[bvssvni]

Currently it creates a new vertex buffer at each call.

It also allocates in .collect() when converting from a flat array to the buffer.

[tomaka]

For performance, it should also use a persistent buffer when available.

[bvssvni]

gfx_graphics uses graphics::BACK_END_MAX_VERTEX_COUNT to compute the size of the buffer upfront, which piston-graphics uses to limit the chunk size. This might be changed in the future to reduce cache misses.

[milibopp]

Removing the allocation would require Glium's buffers to be constructed from slices, I think.

[bvssvni]

Is it possible to update the buffer with slices?

[tomaka]

It's not only a problem of slice vs vec. Creating a vertex buffer is a slightly costly operation due both to the implementation of glium (the background thread thing) and to glium/glium#478. I think that calling collect() would in fact be faster than uploading using a slice, because it avoid a synchronization between the two threads.

The most optimal implementation, in my opinion, uses two persistent buffers.
When you draw something, you map and write the data in the one of the buffers, then draw with it. And every time you draw, you alternate the buffer that you use (first you use buffer A, then buffer B, then buffer A, then buffer B, etc.).

This way you use the CPU to upload the data in the video memory while the GPU is drawing simultaneously.

[tomaka]

I can write the implementation, but we'd need something similar to gfx_graphics's G2D, ie. a struct that persists between draw calls where we can store the buffer.

But that's API-related so I think I'm going to leave this to you.

[bvssvni]

@tomaka Just go ahead if you know what to do. If it gets similar to gfx_graphics then that's fine.

[tomaka]

I'll need to work on glium/glium#481 first

[tomaka]

I'm blocked on glium/glium#482 which is blocked on rust-lang/rust#22156

[bvssvni]

It seems this is already done? Closing.