My feedbacks on project

[adospace]

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]

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:
   

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.

[adospace]

Thanks for the clarifications,

1. Interesting approach to the layout system, in the past I experimented with this too.

A couple of notes from my experience:

• Are you worried about the memory consumption of the cache? are you using or planning to use some sort of buffering? not sure how Skia can help with this
• In MAUI is too easy IMHO to create a widget with an "Auto" size, i.e. GridLength.Auto etc: this forces the layout system to measure far too often. Flutter for example has Row and Column that by default don't require the measure further the tree. Also, Flutter requires you to explicitly "trigger" a measure pass using widgets like Center(), etc.
  I suppose that your layout system could benefit a lot if the UI would not contain things like the above or also properties like HorizontalOptions.Center.
  Do you agree?

[taublast]

Thanks you very much for those notes!

• Actually not worried at all, when controls are destroyed (view/popup/modal closing) their cache is cleared. I watch to be memory-leaks-free, that is the priority along with fps.
  Also one can clear cache when control goes invisible, we have that OnParentVisibilityChanged down-recursive and OnVisibilityChanged proper to any control. At the same time when the cache type is GPU it is cleared automatically in such case.

• Even with children having .Fill etc in an auto-sized layout the layout computation is rather optimized and doesn't suffer from those at all! Here I'm confident. While the current layout system supports feats MAUI has, like auto-size, alignments etc, the calculation is much more optimized than in MAUI, because we had different goals while designing. By the way it's because of that difference in goals here we do not have the default alignment set to Fill but to Start.

The main dynamic performance weak spot if you ask me is that the already rendered surface Is cleared by the canvas at every frame and we must blit not-changed areas along with changed areas.

Main ways for optimization I could see:

A. To rewrite all SkiaSharp renderers to have the last rendered surface not cleared for the new frame, to be able to render only changed areas. ImageCompositeCache type does something similar, but we have to blit the whole bitmap back to the output surface then, this needs to change for a dramatic fps gain.

B. To rewrite the engine for two threads a-la flutter, and that would be possible only after implementing A so that all renderers, especially GPU-accelerated, are totally "background-thread-friendly" for that.

C. And to fully use the DirtyChildren dico for all types of SkiaLayout to avoid remeasurements.