Use a StagingBelt for regular buffer uploads
#92
Conversation
| font_system: &mut FontSystem, | ||
| atlas: &mut TextAtlas, | ||
| screen_resolution: Resolution, | ||
| text_areas: impl IntoIterator<Item = TextArea<'a>>, | ||
| cache: &mut SwashCache, | ||
| mut metadata_to_depth: impl FnMut(usize) -> f32, | ||
| ) -> Result<(), PrepareError> { | ||
| self.staging_belt.recall(); |
There was a problem hiding this comment.
Technically, for lowest memory usage recall should be called right after the user submits the Queue. But this approach removes the burden of a StagingBelt from the user and keeps it hidden.
Worst case scenario, we allocate some additional chunks. Overhead should be constant.
| self.staging_belt.finish(); | ||
| self.staging_belt = StagingBelt::new(buffer_size); |
There was a problem hiding this comment.
As far as I can see, we only need to worry about resizing the belt when the vertex buffer grows, since index buffer uploads will never be bigger than the vertex ones.
6 u32 indices (6 * 4 bytes) are generated per each 4 GlyphToRender vertices (4 * 18 bytes).
`Queue::write_buffer` allocates very regularly, specially on Metal. See: iced-rs/iced#2357 A `StagingBelt` gives us more control and predictability.
grovesNL
force-pushed
the
use-staging-belt
branch
from
9172235
to
153a63b
Compare
|
I just rebased this onto |
Queue::write_bufferallocates very regularly, specially on Metal.See: iced-rs/iced#2357
A
StagingBeltgives us more control and predictability.