Closed TimLariviere closed 2 years ago
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:
Can we have all the Color properties bee theme aware ie for Layouts, Controls , Shapes etc ?
Yes, the plan is to think of all the properties (Colors and others) that make sense to be theme aware and change them to AppThemeBindable
.
Same but for Images from my experience sometime you need to provide a different image for dark mode ?
See my answer above.
For this, maybe we should keep Image
to be not theme aware and have a ThemeAwareImage
that maps to AppThemeBindable properties.
With the recents changes is #10 is still blocked . ?
Yes, still blocked.
Xamarin.Forms.Style
being sealed prevents us from doing anything, unfortunately.
Once this PR is merged . Would you accept PR to add the missing controls following the new structure ?
Yes, absolutely! Fabulous v2 is advanced enough to start adding missing controls. I think I'll open an issue with the list of all missing controls. There we will be able to discuss about 1 and 2 as well
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 let
value in a module will get removed if unused.
I'll try to make AttributeDefinition not rely on AttributeDefinitionStore to make it pure
Also confirmed that having a pure unused
let
value in a module will get removed if unused. I'll try to make AttributeDefinition not rely on AttributeDefinitionStore to make it pure
@TimLariviere I was thinking about this problem, I think it will be possible to store a direct reference to attribute definition in ScalarAttribute
(the same applies for Widget as well).
But there are a couple of thoughts/considerations.
GetHashCode()
for definitions, but we should probably make it statically computed, otherwise it is a cache miss + dynamic dispatch for sorting.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.
I think it will be possible to store a direct reference to attribute definition in ScalarAttribute (the same applies for Widget as well).
Yes, it's what I was thinking too. For the flag optimization, I won't do it in that PR. So you'll be able to work on it after.
A couple of questions:
int
?I think with pure attribute definitions, we can strongly type those in WidgetAttribute
and WidgetCollectionAttribute
.
Perfect!
- Am I right thinking a direct reference will take 64 bits instead of the 32 bits int?
- Is that a potential issue for cache lines?
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 Widget
, though the theory is that we have fewer widgets than scalars, thus we probably have bigger affordance there
Merging this since it's working and already improves tree-shaking. Will work on pure attribute definitions in another PR
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