-
Notifications
You must be signed in to change notification settings - Fork 3
Rethink View DSL structure to enable scaling and improve tree-shaking #52
Conversation
I agree, I think writing by hand makes the most sense given the circumstances. |
This looks fantastic. . Adds some missing control so we I continue migrating my company app to v2 . @TimLariviere Couple questions:
|
Yes, the plan is to think of all the properties (Colors and others) that make sense to be theme aware and change them to
See my answer above.
Yes, still blocked.
Yes, absolutely! |
Interestingly the linker is capable of tree-shaking whole files, even though we have side effects in WidgetDef creation. But unused AttributeDefinitions in the same file than used ones are not removed. So this change of structure enabled removing files whose controls are not used, even if basically nothing changed. |
Also confirmed that having a pure unused |
@TimLariviere I was thinking about this problem, I think it will be possible to store a direct reference to attribute definition in But there are a couple of thoughts/considerations.
So if you have a good feeling how it might all work together then I suggest to "do it", otherwise I may propose to swap tasks: I will do "pure" attribute definitions (I thought about it + it connects to flags optimization I'm tinkering about) you will do "key" property? What are you thoughts? |
I want to take a stab at pure AttributeDefinition to see if we can get fully linked assemblies, and still having a working app.
Yes, it's what I was thinking too. A couple of questions:
I think with pure attribute definitions, we can strongly type those in |
9352a6f
to
84770c5
Compare
Perfect!
|
One of the easier ways to check cache line misses is to introduce 2 floats (8 + 8 bytes) to Scalars (initialized with 0.0). And run benchmarks. I think you will notice the difference both in terms of perf and memory consumptions but it is unlikely going to be huge. I think anything below 10-20% for memory and time is acceptable. We will find other ways to save on memory. The same experiment is applicable to |
Merging this since it's working and already improves tree-shaking. |
Supersedes #42 and #47
Like @edgarfgp suggested in #12, Xamarin.Forms is a "done" API, meaning it won't add breaking changes.
All the focus from Microsoft is now on MAUI.
This means putting effort on CodeGen is not necessarily worth it right now, and we are better off writing all wrappers by hand (it is very time consuming, but much easier than porting CodeGen from v1).
Also, I will continue on my efforts started in #47 about tree shaking, ideally with no allocation more.
Benefits of this PR:
padding
/paddingLayout
=> all are nowpadding
)Typical structure for a wrapped control