RFC: svg cleanup.

[james-lawrence]

removes most of the SVG code from the codebase. relying instead of resvg's implementation. opened as a PR as a proof of concept. it renders more SVGs correctly, downside of course is the additional optional dependencies.

opened as is. I don't intend to do any additional work on the PR (unless its really small). just opened it to demonstrate the idea, and start the conversation.

[xStrom]

Okay, let's try to figure out how to move forward here.

There hasn't been any interest in reviewing this, which is unfortunate. I'm not very familiar with SVG stuff but could do a surface level review.

Regarding the heavier dependencies, given that this whole SVG stuff is behind a feature flag anyway, I think the increase in dependencies can be survived.

On a very fundamental level, if you're saying that this PR would greatly increase the quality of the SVG feature then I think at this point that's a good enough reason to merge.

Which gets us to the point of additional work on this PR, which you already claimed to probably not be interested in. In order for me to merge this, this PR needs to be in a mergeable state and pass CI.

Thus I see two paths forward:

a) You rebase on master and fix the merge conflicts. We pass the CI, I verify that the examples don't crash or otherwise obviously do something very wrong. We merge.
b) We close this PR and continue living with the hodge podge.

What's your take @james-lawrence, how do we proceed?

[james-lawrence]

@xStrom this implementation is standalone it completely replaced the current implementation. I'll follow up later with some misc details regarding the differences between the two.

[james-lawrence]

@xStrom - main differences between the implementations:

• removed upfront font loading. massive performance hit having it vs allowing people to opt into font loading. the performance hit was primarily due to loading it for every image vs having a cached value somewhere.
• overall support for rendering svgs properly is much better in this branch. original version was reimplementing a very sm all subset of the work usvg does.

outside of the font issues IIRC this was api backwards compatible.

fixing up the linting errors and we should be gtg.

[james-lawrence]

we should be gtg. only have the ability to test linux backends personally they all opened and rendered the svg example.

cargo run --features="svg" --example svg # gtk
cargo run --features="svg wayland" --example svg
cargo run --features="svg x11" --example svg

[xStrom]

I tried the example on Windows and the tiger looks low-res. I'm guessing that there's some rasterization happening at the resolution specified in dp (which the Druid widgets operate with), while thinking that is the final physical pixel value.

I wonder if this is a straightforward fix. Maybe we can just ask for a higher res rasterization.

Any thoughts? I'll peek at the code a bit myself too.

[xStrom]

I sort of fixed the scale problem in my local branch. I'll see how easily I could make it mergeable.

[xStrom]

Unfortunately looks like Scale (the info) isn't piped from internals to the widgets yet. The fix is rather easy, and I have it confirmed with a hardcoded 1.75 scale factor as that matches my setup.

I think the move here is to just accept the regression for now and merge. I'll fix up the scale later myself.

[xStrom]

As mentioned earlier, my review here is rather surface level.

• The example still runs fine.
• There is a scale issue, which needs further Druid internals work and I'll document separately.
• I defer judgement of superiority here and just accept the claim.

As such, I think we can merge.