Advanced text

[hecrj]

This PR brings all the improvements that have been introduced in the advanced-text branch. Specifically:

• Text shaping, font fallback, and iced_wgpu overhaul #1697
• Software renderer, runtime renderer fallback, and core consolidation #1748
• Incremental rendering #1811
• text::Shaping strategy selection #1822
• Support configurable LineHeight in text widgets #1828

It's hard to overstate the importance of these changes! All of these features combined make one of the biggest changesets to land in master since the inception of the library!

These efforts should lay the foundations for acquiring maturity in the long run (multi-line text input, accessibility, rendering parallelization, and more!). For more details, check out the latest roadmap diagram.

Closes #33.
Fixes #41.
Closes #1071.
Closes #1199.

[tarkah]

I just noticed after testing the tour example that any longish glyph (like the gs here) is getting cut off at the bottom (tested on windows & linux). Adjusting the to_absolute function for the logical pixels of LineHeight and just adding some manual padding makes the long characters render correctly, so I'm assuming the issue is with the new LineHeight changes. Or perhaps longer glyphs go outside the "bounds" of the text?

I'm noticing the same issue on a personal project with a couple different fonts.

[hecrj]

@bungoboingo @tarkah This is caused by 9a8b30d.

I have incremented the default line height to 1.3 since it seems more readable to me and should prevent this issue. It may be interesting to eventually expose a flag to control the clipping behavior on overflow.

[bungoboingo]

@bungoboingo @tarkah This is caused by 9a8b30d.

I have incremented the default line height to 1.3 since it seems more readable to me and should prevent this issue. It may be interesting to eventually expose a flag to control the clipping behavior on overflow.

Where is line-height measured from with cosmic-text? I would assume it's measured from the bottom of the "descent" of a character, e.g. the tail of a g or p, and then divided evenly to pad the top/bottom of the line. It seems in advanced-text it's being measured from the "baseline" of the line. For example, if I set line height to 1 in Iced, I would expect something like CSS spec (line-height: 1 below).

** Edited to make more clear

[hecrj]

@bungoboingo I would expect the same. Seems it's an issue others have encountered as well: pop-os/cosmic-text#123.

[hecrj]

Hopefully, the 1.3 default line height makes the issue less common. If it still persists, I can revert 9a8b30d for now.

[i509VCB]

One question I have is whether the candidate backend selection should order backends based on the most performant option. I'd think something like this:

1. All hardware adapters for wgpu in the order wgpu enumerates
2. Software renderer
3. Software vulkan implementations (via wgpu)

https://github.com/iced-rs/iced/blob/advanced-text/renderer/src/compositor.rs#L155

[hecrj]

@i509VCB The software renderer can't really fail to initialize and it's always bundled currently. Thus, option 3 would never be reached.

Can we reliably guarantee that our software rendering implementation is more performant than the driver virtual implementations? I don't know if this has an obvious answer or we need to run some actual numbers.

[i509VCB]

Can we reliably guarantee that our software rendering implementation is more performant than the driver virtual implementations? I don't know if this has an obvious answer or we need to run some actual numbers.

I guess the answer is it depends. Lavapipe might be able to use AVX-512 if supported but then there is the issue of compiler overhead. tiny-skia does have some simd support.

Probably needs to be measured anyways.

[hecrj]

@gabrieldechichi I was able to reproduce and fix the issue in #1847.