taublast / DrawnUi.Maui

UI Rendering Engine for .NET MAUI powered by SkiaSharp
MIT License
213 stars 15 forks source link

My feedbacks on project #84

Closed adospace closed 3 months ago

adospace commented 3 months ago

Hi,

Really an interesting project!

I always hoped for a real alternative to Flutter in C# and this project seems a good starting point to write something like that!

I'm curious about a few things: 1) How do you layout widgets? Is there any Measure/Arrange pass before rendering? like in WPF or Maui? 2) Do you think that removing the XAML support would simplify things? Consider an MVU approach where DependencyObject/Property is not required. 3) Do you think that would be, theoretically, possible to remove dependency on .NET MAUI at all? I see that for native controls you're using the MAUI handlers framework (i.e. Editor or Entry), but apart from that one should just create a canvas directly in Android or iOS at startup right?

BTW, awesome stuff, keep it up!

taublast commented 3 months ago

Hi!

  1. Regarding the layout system, actually (actually, because in the future would want to rewrite this to be closer to flutter 2 threads A-layout/prep B-rendering logic) it's we render from the parent view, the top view/views check if they are dirty and start Measure: they measure/layout children, down the tree.
    The Arrange happens if layout is dirty. So that the parent can arrange and control can arrange itself. At any point any control can invalidate self/parent translating this invalidation upper the tree. Upon some tunable logic any control can avoid being invalidated by children. This is the basic concept.
    Also we can have 3 types of forcing redrawing: the Update() that invalidates cache, the Repaint() that keeps self cache but invalidates parent cache only (maybe to just translate/transform self) and InvalidateMeasure() that forces self/parent remeasuring. Also there are dictionnaries and methods tracking which child exactly invalidated, so the layout can avoid remeasuring others. There are some other methods used for more tuned invalidation.
    When measured layouts usually save their structure for later reuse.
    When rendering the resulting structure forms a RenderTree for later reuse by gestures etc. This all has only performance as goal. The real work started on drawn layouts when I had MAUI Grid recalculating everything after any smallest text change inside labels residing inside cells. So no, it's not like WPF/MAUI passes. :) If this all lives up to 2-threads rewriting then this would change a bit obviously for cleaner passes.

  2. One of the next steps was to work this a bit to be able to use fluent syntax, just to use code-behind without XAML to port this to Blazor. So yes XAML is just a way of using it and I already started splitting code into "framework agnostic"/"framework dependent" parts, this will continue. Tried CommunityToolkit.Maui.Markup, would need to choose the best fluent syntax to adopt when this goes to some no-XAML space: image

  3. The answer is yes, without .NET MAUI I would love this to work inside Blazor, to be able to draw on canvas there with user-friendly lego-blocks instead of drawing circles and lines.. :)

If there are some interfaces/other stuff I need to implement to become reactor-compatible please let me know! Would love to test this with some modern C# markup.