Has there been thoughts around how to align iced::Font w/ use of cosmic-text? Does cosmic-text support loading fonts from bytes? I'm sure this is already a known regression, but just want to point it out & start a conversation around it:

• Font::Default / Attrs::new will use the default sans serif font registered w/ the cosmic_text::FontSystem... Fira Sans. If not found, uses a system found fallback.
• Font::External / cosmic_text::Family::Name(..) won't use the included font bytes at all, but will see if there is a matching font family for the provided name on the users system, otherwise uses a system found fallback.

I don't see any way currently to load font bytes w/ cosmic-text or set a default font.

I mentioned some ideas in the Discord, but basically we will change the way iced deals with fonts.

cosmic-text should be able to add support for loading fonts from bytes by leveraging Database::load_font_data.

Attrs allows us to specify style & weight, would be cool to see these added to Text so user can control those attributes as well. I'd imagine Text is going to need to change in order to support these and other changes, together w/ Font

Eventually! Currently just focused on improving the text foundations. API should be accommodated later.

I did some profiling and the bitmap pixels -> lyon tessellation is a huge performance killer. Even on release mode, I'm getting primitive generation times for size 80 text in the 8ms range. This drops to ~400μs when removing the emoji.

Maybe we add a disclaimer to the fill_text docs until there is better support for rastered images w/ transformations.

I ported the new example to master, but it's near impossible compare performance differences between the old / new fill_text since previously this was GPU rendered text and now it's tessellated by CPU. New changes are exposed in primitive generation numbers, but previously the impact would be hidden in render. Both maintain 60fps in release mode.

Obviously the canvas will most likely sit behind a canvas::Cache and in most workflows, the text is fairly static outside applying transformations.

Yes, as I mentioned it's pretty inefficient!

The bitmap support is just a nice to have. For vectorial text, you'll want to deal with fonts that have outline information, so I don't think it's a big deal.

That said, we can probably skip the generic tessellation algorithm and hardcode the triangles ourselves.

Also, important to note that, once we remove glyph-brush, we will be able to compose primitives much more efficiently (a new draw call vs a new render pass). We may be able to use the GPU glyph atlas approach for text that isn't transformed for better readability and performance (with proper layering and caching!).

Lots of doors will open once we get that bottleneck out of the way.

Makes sense!

That said, we can probably skip the generic tessellation algorithm and hardcode the triangles ourselves.

That would be nice. Even though tessellating rectangles should be very cheap, I'd imagine there's still some overhead with lyon that we can get around building the mesh ourselves.

I believe it's as cheap as any other path of 4 points, since we are using the generic path algorithm and not fill_rectangle (which only works with axis-aligned rectangles).