Replaced LayoutSerializer with Async variant #265
Conversation
|
It looks like there is a quite blocking issue with adding in async serialization ...
The potential side effects are ... i guess ... quite obvious. This thus is out of my hand to decide, i would recommend towards the change though. |
|
This will be tricky to get right in terms of avoiding dead-locks for all use cases but I like the idea. If I had the time it is something I might have tried for fun. Out of curiosity I did a quick profiling of the startup of the application we are developing. I focused on the time the UI was frozen since that's what async might solve (I don't expect the total time to change). At first it looked like a large percentage of the time was spent in AvalonDock's methods, but after excluding all time spent loading windows around 10% of the total time was spent in actual AvalonDock code.
What's your main reason for making it async? It feels like I have missed the point or that my application differs significantly from yours. |
|
During initialization I have the need to poll Informations from a Server in some of my documents and cannot decide wether a document should exist or not Prior So i made the whole call chain async to be able to await the possibly non existing documents 🤷♂️😂 |
Make sense. I suspect I could make our call-chain more async as well. Wouldn't make much of a difference on a fast developer machine but it might make a difference with a slow hard drive. We are lucky enough not to have any network calls when opening docked windows. |
|
I am getting compile time errors when I try to compile this. Can you please check if you can fix this? Also, is it possible to keep both options:
There is another PR in the repository that introduces a new property for serialization - do we have to adjust your code for the new property introduced there or will this be covered with your code as well (trying to figure out a sequence in which these PRs should be merged best). Thanx Drk
|
|
@Dirkster99 as I mentioned here #265 (comment) |
|
hmm, I don't mind upping this to Net 4.5 but I am pretty sure a lot of people using this library will not like the idea :-( even though Net 4.0 is quit old in programing terms ...so, I am not really sure what we should do here? |
|
I would argue for upgrading. |
|
Yes I see it the same way in favor of upgrading - an additional argument is that I reviewed the 147 dependent projects (avoiding duplicate forks) and found the counts below. So, to make this also a data driven decision we could go for:
What do you think about that?
|
|
@X39 Do you think you can finish this PR? Otherwise, would you please close it? |
|
The main issue, and the reason i did not continued with with PR, was the .Net dependency thing. If that changed already (and i missed it) i will gladly finish any remaining problems :) @Dirkster99 |
|
Looks like we have chicken-egg problem here. You don't want to make a decision on the platform version but its required to make the suggested change. I don't want to change the platform version without gaining anything in the process :-( ... So how about this. Provided, I update a branch to:
Could you then finish the Async PR to complete the feature and make the update in terms of releasing a new version of AvalonDock worthwhile? |
|
Sure thing 👍 Feel free to raise further concerns regarding the implementation 😉 |
|
Just, for clarification:
Thanks a lot for your time and effort :-) |
|
Hey there, sorry for the late reply yes, willco (tho a little bit later then anticipated by me due to real life :3) |
|
just wanted to add that this is still WIP will notify Dirkster99 again, once done 😉 |
|
@Dirkster99 i consider this now to be complete, |
|
@X39 I don't mind making the old serializer obsolete since 1 serializer should be used in the long run.
I think it would be useful for everyone using the library if we could have same for both cases:
Either way I am thinking that the demo apps should be using the new serializer only to demonstrate their usage and make this simple to test and be consistent with the fact that the old serializer is obsolete and will be removed if everything goes well :-) What do you think about this? Could you please add invocations from the demo apps to the new async serializer? |
|
Blocking is actually problematic due to the UI calls and the whole serializer probably then running on STA thread, making the dispatcher calls cause a deadlock maybe i should undo the obsolete 🙈 regarding the demo, expect that to arrive ~end of next week at earliest |
|
Yeah, I guess we should undo the obsolete then and provide both versions at least for some time but it would still be great if we could provide a few async samples so people can use this without too much tinkering and guess work :-) thanks a lot |
|
Hey @Dirkster99 Removed the obsolete marker, fixed the naming scheme of the async methods and added samples for the serializer to both the docs and the MVVM sample :) |
|
Hey @X39 I looked at the
This known problem was already there before you PR :-( but it can be fixed by using the line below with the corresponding signature change: public MainWindow()
{
InitializeComponent();
this.DataContext = Workspace.This;
this.Loaded += new RoutedEventHandler(MainWindow_LoadedAsync);
//this.Unloaded += new RoutedEventHandler(MainWindow_Unloaded);
this.Dispatcher.ShutdownStarted += MainWindow_Unloaded;
} private void MainWindow_Unloaded(object sender, EventArgs e)
{
Serialize();
}These changes ensure that the Serialization/DeSerialization code is actually invoked as expected but now I am running into a NULL pointer exception somewhere in private async void MainWindow_LoadedAsync(object sender, RoutedEventArgs e)
{
// Deserialize();
await DeserializeAsync();
}
Can you see what I am doing wrong? I guess the particular
Can we make 1. and 2. Async please? There are plenty of other non-async samples in the project so please don't worry removing non-async code in this sample... There is this private void OnLoadLayout()
{
var layoutSerializer = new XmlLayoutSerializer(dockManager);
// Here I've implemented the LayoutSerializationCallback just to show
// a way to feed layout desarialization with content loaded at runtime
// Actually I could in this case let AvalonDock to attach the contents
// from current layout using the content ids
// LayoutSerializationCallback should anyway be handled to attach contents
// not currently loaded
layoutSerializer.LayoutSerializationCallback += (s, e) =>
{
//if (e.Model.ContentId == FileStatsViewModel.ToolContentId)
// e.Content = Workspace.This.FileStats;
//else if (!string.IsNullOrWhiteSpace(e.Model.ContentId) &&
// File.Exists(e.Model.ContentId))
// e.Content = Workspace.This.Open(e.Model.ContentId);
};
layoutSerializer.Deserialize(@".\AvalonDock.Layout.config");
} |
|
I am actually not sure why that null reference exception is happening and sadly cannot reproduce it either
The way the async serializer works is similar to the normal xml serializer (that is: it also uses an event, but an async one) |
|
Mhh, I am confused because I assumed the sample that you added was a proper async serializer :-( |
I am not entirely sure what you mean by that, it is properly async deserializing The event itself is properly awaited |
|
I was referring to you saying this previously:
and I was confused because I thought the sample code we added was a 'proper async example'. Can we add a proper async example using the sample application or is it indeed too difficult? Or is there another issue with that? |
|
Not really difficult, just need a proper (and hence fully) async sample with async loading and initialization of the entire window |
See #264