You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a really cool design, especially given Win2D is leveraged in a very nice way.
However, the output is constrained by the fact that everything has to be rasterized to a bitmap. So the quality of the output is limited. It would be better to have a meta layer that sits along side the Win2D layer so that the display tree could output to other formats, like SVG or XAML.
I suggest you implement this meta layer before you get too far along in your design else it will be very difficult to add later. Most other systems are too heavy handed in the way the meta layer works. Excessive abstraction greatly complicates such designs because the meta layer is then transformed to something native. A nice simple solution is to maintain a Json display tree alongside the Win2D visual elements. It only ever gets used for output, and is not a go between for the Win2D side of things. This parallel display tree could emulate aspects of what SVG and XAML have in common, thus simplifying output to either vector system.
Such an approach would allow you to gradually add this meta layer while continuing to move the rest forward. I would be happy to help with the effort if you add me in on your repo.
Another important design consideration is to move more of your code to .Net Standard. Doing so simplifies unit testing at the component level and opens up the prospect of using some of the work on other platforms.
I like your Win2D "Adorner". I suggest you abstract this a bit further as it is a very critical piece of the solution. An approach I found to be very flexible and easy to tweak is to build the Adorner with SVG regardless of the target platform. The SVG version contains the visual design of the adorner in addition to comments that are used as hints by the display engine that consumes the SVG and renders it natively. The SVG is very simplified, yet has enough detail to drive behaviors of the engine in a programmatic like fashion. I can explain this further if you'd like.
The text was updated successfully, but these errors were encountered:
This is a really cool design, especially given Win2D is leveraged in a very nice way.
However, the output is constrained by the fact that everything has to be rasterized to a bitmap. So the quality of the output is limited. It would be better to have a meta layer that sits along side the Win2D layer so that the display tree could output to other formats, like SVG or XAML.
I suggest you implement this meta layer before you get too far along in your design else it will be very difficult to add later. Most other systems are too heavy handed in the way the meta layer works. Excessive abstraction greatly complicates such designs because the meta layer is then transformed to something native. A nice simple solution is to maintain a Json display tree alongside the Win2D visual elements. It only ever gets used for output, and is not a go between for the Win2D side of things. This parallel display tree could emulate aspects of what SVG and XAML have in common, thus simplifying output to either vector system.
Such an approach would allow you to gradually add this meta layer while continuing to move the rest forward. I would be happy to help with the effort if you add me in on your repo.
Another important design consideration is to move more of your code to .Net Standard. Doing so simplifies unit testing at the component level and opens up the prospect of using some of the work on other platforms.
I like your Win2D "Adorner". I suggest you abstract this a bit further as it is a very critical piece of the solution. An approach I found to be very flexible and easy to tweak is to build the Adorner with SVG regardless of the target platform. The SVG version contains the visual design of the adorner in addition to comments that are used as hints by the display engine that consumes the SVG and renders it natively. The SVG is very simplified, yet has enough detail to drive behaviors of the engine in a programmatic like fashion. I can explain this further if you'd like.
The text was updated successfully, but these errors were encountered: