Add path drawing to software renderer

[stellar-aria]

This is my first real foray into graphics programming (and serious Rust), so please forgive me for any mistakes.

This adds path rendering support to the software renderer with the Zeno crate as per the recommendation at #4178 (comment). This closes #4178 and would supersede #6032.

In theory this should be no_std compatible, but that's currently blocked by lyon_path/lyon_geom requiring std due to a bug in lyon_geom. Once the PR addressing that is merged we could move lyon_path/lyon_geom off of the std feature and use their internal dependents (PathDataIterator) in a no_std environment.

Details:

• add zeno to the Cargo manifest, conditionally enabling std/libm depending on the i-slint-core features.
• add process_filled_path/process_stroked_path to the ProcessScene trait
  • This is currently only properly implemented in RenderToBuffer<'_, B>, not PrepareScene, since I didn't add path rendering variants to SceneCommand, and there's not really an easy way to render paths line-by-line that I could think of. Suggestions welcome!
• Implement draw_path:
  • Pretty standard stuff, it converts the internal Path commands to Zeno's, figures out the geometry and if the clip mask completely excludes it, skips rendering altogether.
  • If rendering is needed, then it calls the relevant processor function
• Add a path module
• Implement convert_path_data_to_zeno
• Implement render_path_with_style
  • This function does the actual rendering, clipping, and compositing
  • The path is rendered to a mask in a buffer that matches the size of the requested geometry
  • Iterates through the post-clipped visible region, compositing the newly rendered mask onto the output buffer
• Implement the render_filled_path and render_stroked_path forwarding functions

I ran into this because we needed it for a hardware simulator for an embedded device potentially using slint, where the simulator GUI is using Iced and embedding the output of the Slint software renderer into the location of the display. Some of our elements are Paths since they're directly imported from an SVG/design file.

As you can see, both the primary curve (which is placeholder for the actual software-generated shape) and the small once/loop icon in the lower right are now visible and both are Path objects.

[ogoffart]

Really nice, thank you very much.

Just one detail would be to try to keep this optional when running on MCU in no_std environment where we want to keep the binary as small as possible.

[stellar-aria]

I'm not entirely sure why the build failed there

[ogoffart]

I'm not entirely sure why the build failed there

Error: Process completed with exit code 143.

We've seen that error before. I think this could be that the CI machine runs out of memory. Re-trying.

[ogoffart]

This is good.
And it really doesn't impact anyone who is not opting it for it.
And so I see no objections in merging it.

But on the other hand, this is never used.
User only can opt in to it by enabling internal crate.

I think it should be done similar to software-renderer-systemfonts:

• enabled by default for linuxkms and winit backend
• have a way to enable it from the slint crate features.

I would say that ideally the feature should automatically be enabled if both std and software-renderer feature are on, but I think that's a bit hard to do with Cargo. Unless we split the software renderer in its own crate, but that's another thing.

[meowcakes]

Any plans to support this in no_std now that the relevant PR has been merged?

[stellar-aria]

Any plans to support this in no_std now that the relevant PR has been merged?

I've got a branch with the relevant changeset, just haven't rebased on current master and created a PR yet.