Skip to content
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

PathIconSource claims to support sharing but throws exception (AKA shared Geometry issue) #827

Closed
verelpode opened this issue Jun 7, 2019 · 4 comments
Labels
needs-triage Issue needs to be triaged by the area owners no-issue-activity team-Rendering Issue for the Rendering team

Comments

@verelpode
Copy link

A very common requirement is to use the same icon/symbol in multiple different buttons/places within an app. Nearly every non-trivial app needs this ability. The documentation for PathIconSource says this is supported:

PathIconSource is similar to PathIcon. However, because it is not a FrameworkElement, it can be shared.

It says it can be shared but if you try to share it, ArgumentException (HResult=0x80070057) is thrown. SymbolIconSource shares successfully but not PathIconSource.

Actually the underlying problem is that Geometry fails to share when you use the same Geometry instance with multiple instances of IconSourceElement or PathIcon or Shapes.Path.

In comparison, the older WPF-Desktop does support sharing of Geometry instances provided that you first invoke Geometry.Freeze (Freezable.Freeze). Unfortunately UWP does not support Freeze. (It supports Style.Seal but not Freeze.)

To work around this problem in UWP, we're forced to clone the Geometry instances whenever they're used in multiple places (very wasteful!), but how should that be done? UWP does not support the System.Windows.Media.Geometry.Clone method. For app authors to implement their own version of Clone is no small task because it requires manually copying all properties of all subclasses of Geometry, PathFigure, and all subclasses of PathSegment. Furthermore it's wasteful to have multiple clones of the same icons in RAM. It's also a substantial performance hit because whenever you create a new instance of a Page or UserControl, you must first clone all the icons/Geometry instances that the Page uses.

The problem of cloning Geometry is further worsened by the fact that UWP also lacks support for the "capacity" parameter in the constructor of PointCollection necessary for PolyBezierSegment.Points and other subclasses of PathSegment. The missing "capacity" parameter means that when you clone a PointCollection, the internal data is repeatedly reallocated/resized unnecessarily. This makes cloning even more expensive.

WPF-Desktop also has System.Windows.Media.StreamGeometry which is great for making efficient shared path-based icons, but again this feature is missing in UWP unfortunately.

Expected behavior

  • PathIconSource should do what the documentation says it does ("it can be shared"), meaning the ArgumentException should be eliminated.
  • It would be nice if Shapes.Path also supports shared Geometry but this is non-essential if at least PathIconSource supports sharing.
  • I like WPF's Geometry.Freeze (Freezable.Freeze) (and also UWP's Style.Seal) but I'd also be happy if the shared-icon solution is implemented in a different manner than Freeze or Seal.
  • In any event, please also support the "capacity" parameter. Even if the need for cloning is eliminated, the capacity parameter is still needed in other cases such as when deserializing a point list from a file, or when converting an SVG Path to a Xaml Geometry. Any case of building a PathGeometry can benefit from the capacity parameter.
  • Ideally UWP would also support an equivalent of System.Windows.Media.StreamGeometry, but the highest priority is to eliminate the ArgumentException when PathIconSource is shared.
@verelpode
Copy link
Author

In response to a suggestion from @be5invis, here is more info on the icon topic.

Icons are a very important topic, considering that most apps uses multiple icons in multiple places in multiple kinds of GUI elements (icons in buttons, toolbars, menus, tabs, standalone, etc). Thus it's surprising to observe that, currently, icon rendering hardly works in WinUI/UWP unfortunately.

Example 1:

Look at a really simple case where you have an instance of Windows.UI.Xaml.Media.Imaging.BitmapImage that was produced from a PNG, and you want to use this PNG BitmapImage as an icon. That should be super simple, right? But no, unfortunately neither Windows.UI.Xaml.Controls.BitmapIconSource nor Windows.UI.Xaml.Controls.BitmapIcon support the ability to render a specified instance of BitmapImage -- surprising but true.

Example 2:

You have an instance of Windows.UI.Xaml.Media.PathGeometry that you want to use as a monochrome vector icon in multiple places or pages in your app. Again that should be super simple, right? But no, unfortunately exceptions are thrown whenever you try to use/share the same instance of a Geometry in multiple different instances of Windows.UI.Xaml.Controls.PathIconSource, Windows.UI.Xaml.Controls.PathIcon, or Windows.UI.Xaml.Shapes.Path.

Example 3:

You have an SVG file that you want to use as an icon in multiple places in your app. Again you're out of luck because the SVG renderer contains bugs: See issue #825

@github-actions
Copy link

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Aug 3, 2023
@Mangepange
Copy link

Seems like this is still an issue. Are there currently no way of sharing data for PathIcons?

@microsoft-github-policy-service microsoft-github-policy-service bot added the needs-triage Issue needs to be triaged by the area owners label Jun 26, 2024
@KubaO
Copy link

KubaO commented Sep 11, 2024

This needs to be reopened. It is still a problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-triage Issue needs to be triaged by the area owners no-issue-activity team-Rendering Issue for the Rendering team
Projects
None yet
Development

No branches or pull requests

4 participants