Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Section and allocations #155

Open
DavidVonDerau opened this issue Sep 23, 2022 · 1 comment
Open

Section and allocations #155

DavidVonDerau opened this issue Sep 23, 2022 · 1 comment

Comments

@DavidVonDerau
Copy link

The glyph_brush API takes a Section to queue, but the Section internally uses a Vec to hold text. If I have a bunch of fields to write to the screen in different locations and with different bounds, it seems like each distinct field will force an allocation of a Vec with a capacity of 1.

I'm not sure if I'm using the API wrong, or if I've missed something.

If this is how the API works, would you be interested in a PR that changes Section to use a smallvec or other optimization for the scenario when a Section only hold a single string?

@alexheretic
Copy link
Owner

You are not mistaken. However, iirc my previous testing I would predict it not significant to the overall performance of drawing text
(text layout, glyph rasterization, vertex generation & caching all being relatively much more expensive).

With that said if such changes would positively impact the benchmarks, or some new meaningful benchmark, it would be interesting and could point the way to better designs.

The other issue is changing away from Vec in Section would be breaking, something I'd probably avoid without big win.

You can run the existing benchmarks with, for example cargo bench --bench glyph_brush

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants