-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement compile time MergedDictionaties #9577
Conversation
259aa21
to
c03187f
Compare
You can test this PR using the following package version. |
Can I still swap out a resource dictionary during runtime? I use it for example for translations |
As long as you use regular |
You can test this PR using the following package version. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't speak for the implementation (this is @kekekeks' area, and yours I guess ;) ) but I've been wanting this feature for ages!
There's been some internal discussion about whether this should be a separate element or a compiler directive, i.e. <MergeResourceInclude>
or something like <ResourceInclude x:Merge="True">
.
I think the main reason that <MergeResourceInclude>
was chosen was that it won't cause errors in designers that aren't aware of this directive, but someone may want to give more details here.
You can test this PR using the following package version. |
What does the pull request do?
Replaces:
and
with equivalent of:
(The first xaml file is still available for the ResourceInclude, at least with current implementation)
Important to mention, that this PR at current state is half efficient, because our theme-variant resources cannot be merged into a global theme. Because we have to attach/detach them in runtime to get working theme switch. This completely not forgotten PR aims to solve this by introducing ThemeDictionaries, which also can be merged into a parent ThemeDictionaries.
Also, no merging for StyleInclude was done in this PR. It might give us a slight improvement, but I doubt it will be any significant due to differences how they are resolved.
Breaking changes
If we remove original resources, then it won't be possible to ResourceInclude parts of the theme.
It wasn't done yet in this PR. Not sure if we need it. But it could save some kilobytes of app size.
Benchmarks
I run couple of different benchmarks that depend on our XAML themes + a new one.
Results are based on this branch and master branch (which already has #9413 included). I planned to do another run of benchmarks on a commit before #9413 was merged, but there are too many other PRs were merged in between (including the great interface removal (tm)) making it not very reliable.
FindFluentControlTheme
A new benchmark, which shows the most improvement.
Before this PR resource lookup had to iterate over each ResourceInclude looking for the control theme. The more controls (and ResourceIncludes), the slower it is.
After this PR it just looks up merged dictionary (partially merged due to limitations explained above). Shouldn't be much slower with no matter how many controls we have.
There also is the same benchmark for Simple theme, but it shows same relative improvement, so I removed it to avoid informational noise.
Master:
This PR with merged resource dictionaries:
InitFluentTheme/InitSimpleTheme
This benchmark creates a fluent/simple theme and resolves a single resource from there.
Not a huge difference, except Simple them. No idea what happened there, but I suppose it became even more simple (IL-wise).
Master:
This PR with merged resource dictionaries
Create control benchmarks
SimpleTheme is used.
Marginal improvement, but still an improvement.
Master:
This PR with merged resource dictionaries:
Other metrics affected by this PR:
Avalonia.Themes.Fluent
binary size: increased from 3.3mb to 3.6mb. Because we basically duplicate resource definitions now by saving original files in the assembly. If we remove original ones, it will be improved, but users won't be able to include parts of the theme.