Efficient usage of multiple TextBrush instances

[eseaflower]

Hi and thanks for your work with wgpu-text.
I want to use wgpu-text to draw text into several different views within a render pass (using RenderPass::set_viewport). The options I have considered so far are:

1. For each viewport within the render pass, queue the text for the viewport and then render it immediately. Repeat this for each call to set_viewport. This seems innefficient since the cache in glyph_brush is flushed on each draw call, retaining only the data in the most recent render.
2. Use separate TextBrush instances for each viewport. This enables queueing of the text before rendering and each viewport will have its own cache. The downside of this approach is that we also end up with a separate wgpu::RenderPipeline for each instance and multiple invocations of shader compilation each time the number of viewports change.

One way to overcome this limitation is to allow the creation of a TextBrush with a 'shared' wgpu::RenderPipeline. The idea would be that multiple instances of TextBrush could share a RenderPipeline while still maintaining seprarate vertext buffers and caches. I'm thinking this could be exposed via something like BrushBuilder::with_shared_pipeline().

What do you think, is this something you would like me to implement?

[Blatko1]

Thank you for using this crate!
I have bumped into similar problems here and have found that the glyph_brush dependency crate is made explicitly so all queued data is rendered in one draw call. In other words, all data is being flushed on each draw() call. This means you would end up recreating the glyph_brush render data on each draw occasion.
Please elaborate on which limitation does your solution fix.
I don't see any benefits from having multiple TextBrush instances with shared RenderPipeline because you would still need to queue the data before each draw, and you would still need to use multiple RenderPasses. I would recommend using the first option you wrote about.

[eseaflower]

My solution would enable multiple instances of TextBrush to share the underlying wgpu::RenderPipeline. I have a scenario that is similar to the following pseudo code:

// Represents a view within the surface
struct View {
    viewport: Extent2d,
    brush: TextBrush,
    flat_shapes: Vec<FlatShape>,
    textured_shapes: Vec<TexturedShape>,
}

// Holds data for all views that should be drawn to the surface
struct Scene {
    views: Vec<View>,
    text_pipeline: wgpu::RenderPipeline,
    flat_pipeline: wgpu::RenderPipeline,
    textured_pipeline: wgpu::RenderPipeline,
}

fn draw() {
    ...

   {
        let mut render_pass = encoder.begin_render_pass(&render_pass_descriptor);

        // Draw all flat shapes
        render_pass.set_pipeline(&self.flat_pipeline);
        for view in &self.views {
            render_pass.set_viewport(view.viewport);
            view.render_flat(&mut render_pass);
        }

        // Draw all textured shapes
        ...

        // Draw text
        render_pass.set_pipeline(&self.text_pipeline); // Using a shared pipeline for all text rendering in all Views

        for view in &self.views {
            render_pass.set_viewport(view.viewport);
            view.render_text(&mut render_pass);
        }
    }

    queue.submit(iter::once(encoder.finish()));
}

The different Views are independant so I want multiple instances of TextBrush to benefit from the caching done in the brush. This should be efficient since the text in the views does not change much between frames. I can almost implement the solution above with the current version of TextBrush, but I would end up with different instances of the wgpu::RenderPipeline (eventhough they would all be identical). This seems inefficient and if the number of Views change it would lead to creating and destroying a lot of RenderPipelines.

[Blatko1]

    // Draw text
    render_pass.set_pipeline(&self.text_pipeline); // Using a shared pipeline for all text rendering in all Views

    for view in &self.views {
        render_pass.set_viewport(view.viewport);
        view.render_text(&mut render_pass);
    }

As I understand, in the code above, you are rendering text multiple times in the same render_pass, meaning you are rendering it on the same render target (view), but each time you specify a different viewport. Please tell me the usage for the provided code and specify what exactly the render_text() function does.
Also, the provided code doesn't follow the wgpu encapsulation rules, or, in other words, rules for the middleware graphics libraries like this one.

I suppose the main point of all this is to render the same text data onto multiple render targets (views) while having to recreate glyph_brush data only once (not having to recreate it on every call). In that case, you can define multiple color_attachments (views) in the RenderPassDescriptor so you'd render the same data in a single render pass without recreating glyph_brush data multiple times.

[Blatko1]

What exactly are you referring to when using the word view? I am referring to the render target onto which everything is being drawn in each render_pass. The view is of type TextureView and is used in the RenderPassColorAttachment.

[eseaflower]

I am using a single TextureView. This single TextureView is divided into several logical views (what I callled View above). These, let's call them subviews, are filled with data to be rendered, among it text data. The subviews are all independant, so it is not the same text that is drawn in each subview, but different text. I need to call set_viewport() since I need the transformation and clipping to be per subview. The number of subviews, their size and position, is changeable by the user.
I think this setup is best solved by a separate TextBrush-instance per subview. Using a separate instance per subview gets the benefit of caching per subview. The downside to using a separate TextBrush-instance per subview is that we end up with a separate RenderPipeline per subview. I am not an expert on wgpu and maybe these duplicated RenderPipelines are not an issue, but it seemed that somehting better could be done.

[Blatko1]

Ok, now I understand what you mean by view. In wgpu, the surface onto which you are rendering through the render pass is usually called a view. I fully understand your problem and see that many changes must be made to avoid complicating the library.

You can have multiple text sections in different places and render them all at once with unique clipping for each, but the main problem here is changing the inner matrix and having different transformations. Different matrix settings can only be set once per each render. Is having unique transformations and matrix settings for each text section really necessary for your use case?

While it may take longer to implement this change, there may be a crate already capable of doing this. For example, glyphon is a crate similar to this one but has some other dependencies.