These are chat archives for AvaloniaUI/Avalonia

8th
Nov 2018
Nikita Tsukanov
@kekekeks
Nov 08 2018 05:10
We should explicitly state that anything that happens before Setup and is trying to use Avalonia might and will fail
Including SynchronizationContext.Current
Steven Kirk
@grokys
Nov 08 2018 07:32
it's fine to state it, but people don't read docs. if we can fix it it would be much better.
ahopper
@ahopper
Nov 08 2018 07:35
:+1: but if it can't be prevented the place to put the warning is in the project templates
Nikita Tsukanov
@kekekeks
Nov 08 2018 07:38

if we can fix it it would be much better.

Capturing SynchronizationContext.Current will never work

Steven Kirk
@grokys
Nov 08 2018 08:11
could you explain why it will never work for avalonia? the other frameworks manage it
Nikita Tsukanov
@kekekeks
Nov 08 2018 08:23
They don't
There is nothing to initialize synchronization context at the beginning of Main
It's the same with WinForms
I think it's one of the reasons why WPF project template doesn't have Program.cs by default
And forces you to write your code in App.xaml.cs/MainWindow.xaml.cs instead
Since things are properly initialized at that point
Andrey Kunchev
@donandren
Nov 08 2018 08:28
hm i remember i had some problems with unittests and SynchronizationContext.Current null in the past and fixed it with Fody.ModuleInitializer to init the sync context
Nikita Tsukanov
@kekekeks
Nov 08 2018 08:28
We also have an issue with our Dispatcher
That caches IPlatformThreadingInterface from AvaloniaLocator in it's static ctor
So, if it gets accessed before Setup
CheckAccess will always return true
Also, signaling won't work
We need a way for App.xaml.cs to return Application's main window
So people won't get confused
By MainWindow existing in Program.cs
Jeremy Koritzinsky
@jkoritzinsky
Nov 08 2018 08:31
Maybe something similar to Prism's bootstrapper?
Nikita Tsukanov
@kekekeks
Nov 08 2018 08:33
Alternatively we could rework our template to be something like that:
static void Main(string[] args)
{
       // Avalonia isn't set up at this point, don't use *anything* UI-related here (including your view models)
       BuildAvaloniaApp().SetupWithoutStarting();
       AppMain(args);
}

static void AppMain(string[] args)
{
      // your code here
}
That will require a rework of AppBuilder that's currently not quite friendly with SetupWithoutStarting approach
Jeremy Koritzinsky
@jkoritzinsky
Nov 08 2018 08:34
That could work. Though at that point I'd say we should rework AppBuilder.
Nikita Tsukanov
@kekekeks
Nov 08 2018 08:34
Since it doesn't allow to call Start<TWindow> after SetupWithoutStarting
Jeremy Koritzinsky
@jkoritzinsky
Nov 08 2018 08:35
Maybe rebuild it or a replacement on top of the ASP.NET Generic Host as I mentioned offhand a while back? Then we could more likely provide an API surface for startup that better fits what some of our users might already know. Would take a lot more work though.
Nikita Tsukanov
@kekekeks
Nov 08 2018 08:36
Blazor uses Startup.cs approach
I don't see why we shouldn't
We have App.xaml.cs though
Which is kinda our Startup.cs
Generic host also provides some DI support
Avalonia currently doesn't interfere with app's DI in any way
We currently don't impose any conventions on user's application in terms of DataContext management
Jeremy Koritzinsky
@jkoritzinsky
Nov 08 2018 08:39
I think the DI for generic host is optional or at least will be in the 3.0 release.
Nikita Tsukanov
@kekekeks
Nov 08 2018 08:39
For example egram.tel uses some kind of MVC approach
ASP.NET 3.0 will be .NET Core only
Jeremy Koritzinsky
@jkoritzinsky
Nov 08 2018 08:39
The Microsoft.Extensions packages are staying netstandard
I have to head to bed. It's getting really late here. I'll talk to you more later.
Nikita Tsukanov
@kekekeks
Nov 08 2018 08:40
netstandard2.1 won't be compatible with .NET 4.x
Jeremy Koritzinsky
@jkoritzinsky
Nov 08 2018 08:40
I don't know if that package is upgrading from netstandard2.0
Nikita Tsukanov
@kekekeks
Nov 08 2018 08:45
static void Main(string[] args)
{
       // Avalonia isn't set up at this point, don't use *anything* UI-related here (including your view models)
       BuildAvaloniaApp().Start(AppMain, args);
}

static void AppMain(App app, string[] args)
{
      app.Run(new MainWindow());
}
Something like that should be enough, I think
Jeremy Koritzinsky
@jkoritzinsky
Nov 08 2018 08:53
Yeah that should work!
Steven Kirk
@grokys
Nov 08 2018 08:55
yeah, i like that!
Artyom
@worldbeater
Nov 08 2018 09:27
BTW folks how do you edit project templates in AvaloniaVS repo? https://github.com/AvaloniaUI/AvaloniaVS/blob/master/src/Templates/AvaloniaMvvmApplicationTemplate/ViewModels/MainWindowViewModel.cs is there a converter that will turn a demo project into a template or should one do that manually by replacing namespaces names to $safeprojectname$ (in case yes, how to handle testing)?
Hmmm
@worldbeater Visual Studio does the substitution
Template files are packaged as package content
Artyom
@worldbeater
Nov 08 2018 09:32
Thank you! Gonna check it out
AvaloniaVS is only for Visual Studio and another one is only for dotnet new right?
Nikita Tsukanov
@kekekeks
Nov 08 2018 09:39
+
Steven Kirk
@grokys
Nov 08 2018 09:41
@worldbeater they should both be the same
are there differences?
i wish VS could use the dotnet template engine. it's so much easier for writing templates
btw last month i did some performance work, but didn't submit the PRs because of the upcoming release. i'm starting to submit the work now, here's the first: AvaloniaUI/Avalonia#2085
Nikita Tsukanov
@kekekeks
Nov 08 2018 09:46
Could we add some global "version" variable for everything and use it as cache invalidation flag for our "full" properties?
If anything related to full properties infrastructure changes version gets incremented
Then we could cache property values and if current global version matches the last local one return the cached value
Steven Kirk
@grokys
Nov 08 2018 09:48
well for simple properties that just have a local value, their lookup essentially just involves a dictionary lookup now
part of the problem here was that TemplatedParent was inherited. we could definitely store inherited values more intelligently
Nikita Tsukanov
@kekekeks
Nov 08 2018 09:48
I think UWP has some special data structure for property values
Steven Kirk
@grokys
Nov 08 2018 09:49
however, i did an initial spike of that and it didn't really make much of an impact on the profile
thing is, for the amount of times TemplatedParent is looked up, even a simple Dictionary.TryGetValue shows up pretty high on the profiling!
given the fact that it's such a hot spot and inherited property semantics aren't really needed, it was easier to just make it a direct property
i was taking the approach of profile-guided optimization where i tried to profile the most expensive operation
Steven Kirk
@grokys
Nov 08 2018 09:54
there's definitely a lot more to do though, and improving the property store will surely come up
Nikita Tsukanov
@kekekeks
Nov 08 2018 09:54
There might be some issues with direct property calls not being inlined
Steven Kirk
@grokys
Nov 08 2018 09:54
any idea what data structure UWP uses?
Nikita Tsukanov
@kekekeks
Nov 08 2018 09:54
because of interfaces
Steven Kirk
@grokys
Nov 08 2018 09:55
could be
but the thing that just keeps coming up on profiling is Dictionary.TryGetValue
which by all accounts is pretty fast!
Nikita Tsukanov
@kekekeks
Nov 08 2018 09:56
Are we using string dictionaries?
Might be worth to replace strings with indices
And do an array table lookup instead
Steven Kirk
@grokys
Nov 08 2018 09:57
https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Base/ValueStore.cs#L11 where AvaloniaProperty has an Equals which compares it's int Id
replacing the key with the int ID is something we should do
but my main focus (after the PR I just submitted) was reducing the number of property reads
for example - to show the calendar page, 587554 style selectors were being evaluated
587554!
Nikita Tsukanov
@kekekeks
Nov 08 2018 09:59
Simple array might consume more memory though
Steven Kirk
@grokys
Nov 08 2018 09:59
i actually tried a simple array. it improved things, but not by as much as you'd expect!
i instead worked on intelligently caching which styles can apply to which classes
Nikita Tsukanov
@kekekeks
Nov 08 2018 10:00

587554 style selectors were being evaluated

Mozilla has created a new programming language to process their CSS selectors on multiple threads

Steven Kirk
@grokys
Nov 08 2018 10:00
i got the 587554 style selector evaluations down to 60738, which is still a lot
ahopper
@ahopper
Nov 08 2018 10:00
I tried that(array) too :) even if the valuestore was perfect it only makes a few percent difference
Steven Kirk
@grokys
Nov 08 2018 10:01
yeah
the optimizations need to come higher up the stack IMO
we're just doing too much
and not being intelligent about it
tbh i knew that when write the styling stuff
my intention was always to come back and optimize it
evaluating styles on b/g threads is something i've thought about, but they need to read properties which we only currently allow from the main thread
i can think of ways around that, but for the moment there are easier gains to be had
for example, don't try to apply every single Button style to every single TextBlock etc
ahopper
@ahopper
Nov 08 2018 10:20
yep just making every method faster will come no where near what is really needed.
ahopper
@ahopper
Nov 08 2018 10:26
because everything causes everything else to happen in the initial measure I found it hard to apportion blame to specific areas using the profiler
my next plan was to try and do this
ahopper
@ahopper
Nov 08 2018 10:32
I failed to get method call counts in the profiler, this might be very useful in catching things being called more often than they should
Steven Kirk
@grokys
Nov 08 2018 10:34
this is what i was talking about: AvaloniaUI/Avalonia#2088
@ahopper yeah i find dotTrace much better than the VS profiler for this. I also set up a test harness that starts profiling programatically just for the layout stage
Steven Kirk
@grokys
Nov 08 2018 10:40
i think the next stage after #2088 is to cache the styles not only by control type but by (control type, templated parent type)
but as i say, i'm choosing what to target by profiling and there are other things to tackle first that are talking more time
as an aside: one of the problem i'm finding is that the results are totally different in debug vs release mode
i'm only targeting release mode atm
Nikita Tsukanov
@kekekeks
Nov 08 2018 10:46
End users will be consuming release binaries
We probably want to provide NGen'ed native images as well
Steven Kirk
@grokys
Nov 08 2018 10:50
yeah, that's why i've been targeting release. we may want to target debug at some point too, but we shouldn't make that a priority IMO
Wiesław Šoltés
@wieslawsoltes
Nov 08 2018 12:41
I have release early version of Avalonia Theme Editor https://github.com/wieslawsoltes/ThemeEditor/releases/tag/0.0.1
Steven Kirk
@grokys
Nov 08 2018 19:37
@Gillibald can you ping me tomorrow to remind me to review the tabcontrol pr? I've just got too many things to remember!
Sorry I've left it to linger for so long
I think I need to sign up for a todo app
Benedikt Schroeder
@Gillibald
Nov 08 2018 21:58
@grokys Will do. Currently very busy but will make sure we get this merged soon.
Steven Kirk
@grokys
Nov 08 2018 23:36
yeah totally understand! we're all in the same boat