-
Notifications
You must be signed in to change notification settings - Fork 692
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: New, decoupled SVG rendering #3666
Comments
🦙 I believe Win2D itself has better support for SVG, there's a wrapper based on Win2D here and a Skia based one here with it's own SourceGenerator version here too. I think it'd probably be best to just build on top of one of these solutions and if anything provide better hooks for dynamic XAML/Binding/Themes/Animation using them instead. |
I don't think so, Win2D just delegates the work to D2D which is what XAML uses too. See the link at the bottom of that doc to https://docs.microsoft.com/en-us/windows/win32/direct2d/svg-support?redirectedfrom=MSDN |
Even if it doesn't, I'm hopeful for some sort of notice in the WinUI 3 RTM release commenting that SVG output may not be identical. As I understand it, otherwise changing it could be considered a breaking change which couldn't go in a 3.X release. |
Please don't throw the baby out with the bath water. SVG in more places and better rendering in WinUI 3 is an excellent proposal, so long as interfaces remain standardized. Unfortunately, too often, personal syntax and grammar preferences seem to change elements wholesale with no improvement in the engineering. Interfaces do not need to be "beautiful" or "elegant" or be "a joy to program" please. |
Why would you assume that the interfaces would change when the entire request is to change the underlying implementation? This issue is in no danger of reaching that scope and your comment doesn't feel like it belongs in a GitHub thread of this scope. |
Proposal: Introduce a new, decoupled SVG rendering system to replace the UWP option
Summary
UWP SVG rendering is relatively slow and lacks substantial features compared to many modern SVG renderers, so a change would be appreciated.
The first goal of this would simply be to no longer guarantee that SVGs render the same in dot releases, to allow for future work in replacing SVG rendering.
Rationale
Scope
Worth noting -- I don't have a candidate library in mind. I just know that there are a lot of people itching for SVG in more places in WinUI, UWP, and throughout the Windows GUI, and the groundwork of decoupling the SVG rendering seems important toward this goal.
The text was updated successfully, but these errors were encountered: