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

Problems with the GlyphBrush::process_queued method #119

Open
wolfiestyle opened this issue Aug 16, 2020 · 3 comments
Open

Problems with the GlyphBrush::process_queued method #119

wolfiestyle opened this issue Aug 16, 2020 · 3 comments

Comments

@wolfiestyle
Copy link

  • Can't easily make it return more than one vertex per glyph. It could be done by using an emit_vertex FnMut closure argument instead of returning it via BrushAction.
  • Each call allocates a new Vec with vertices. The method could instead take a T: Extend<V> so the user can reuse a single buffer, or just return vertices with a closure as said above.
@alexheretic
Copy link
Owner

On the first point, you can have your vertex type as an array type. In my experience you get better performance from one vertex per glyph + instance rendering, so the API encourages that.

On the second, I imagine the allocation cost of the vertex vec is not significant compared to the cost of layout & draw cache interactions. When there is no text changes (most frames) there also isn't any vertices returned (BrushAction::ReDraw) so no issue. That's my feeling on that, but feel free to have a go and look at the benchmark performance of such a change.

@wolfiestyle
Copy link
Author

That only works if you call process_queued once per frame. If not you're basically not using the cache at all, and emitting new vertices constantly. In a real application you'll probably want to mix between drawing text and other UI elements. The current API seems optimized to a specific use case, and inefficient at others.

@alexheretic
Copy link
Owner

The api is indeed designed for one process_queued call per frame per brush/pipeline. There's a lot to gain by hitting the cache and avoiding not only calculations but the vertex upload to the gpu pipeline. If you need multiple pipelines for multiple draws per frame you can use multiple GlyphBrush instances.

For example, in Robo Instructus I do use a few instances.

The api is trying to push you in a performant direction, keeping in mind the gpu pipeline. It's not perfect, and I am trying to think of better and more flexible API designs, but I think it'll always try to steer toward performance as that is the point of glyph_brush.

If you need more control right now, you can opt to use ab_glyph directly (perhaps with glyph_brush_layout & glyph_brush_draw_cache).

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