hecrj
commented
4 years ago Resizing the window after creation has unwanted side-effects.
Do you mean for your particular use case? wgpu_glyph should work well as long as you resize your swap chain correctly.
Using wgpu_glyph it does not appear that I am able to do this, at least without creating the GlyphBrush twice.
Could you elaborate a bit on this? You only need wgpu::Device to create a GlyphBrush, which can be obtained in wgpu without a window. You do not need a window for rendering either, as you can obtain a TextureView from any Texture. Maybe there is something particular to your use case that I am missing?
In any case, I agree that the GlyphBrush struct is doing way too much stuff. We should split it and define clear boundaries, maybe exposing the Cache as a first-class concept of the API.
I will most likely end up building a new text rendering crate at some point for iced with text shaping support. I'd like to wait until then before refactoring wgpu_glyph.
dhardy
I wish to calculate an optimal window size (using
GlyphCruncher::glyph_bounds), then create that window. Resizing the window after creation has unwanted side-effects.Using
wgpu_glyphit does not appear that I am able to do this, at least without creating theGlyphBrushtwice. Yet from examining the source, it appears that the only reason for this is thatGlyphBrushencapsulates both theglyph_brushand thepipeline.Probably the simplest solution (though awkward) is to allow a
GlyphBrushto be created from an existing object of the upstreamGlyphBrushtype.