These are chat archives for AvaloniaUI/Avalonia

3rd
Jan 2019
mstr2
@mstr2
Jan 03 05:01
Is it planned to replace decorative naming like AvaloniaList, AvaloniaDictionary, etc. with more semantic naming like ObservableList, ObservableDictionary, etc.? My feeling is that some parts of the API are a bit clunky at the moment and could be improved with careful renaming.
Jeremy Koritzinsky
@jkoritzinsky
Jan 03 05:09
I think we might keep those names since each of those types have behaviors/features specific to what Avalonia needs for some internals (at least in the AvaloniaList case).
I don't think renaming them to ObservableList and the like would make the naming much more useful.
mstr2
@mstr2
Jan 03 05:20
Sure, but that's why they are in the Avalonia namespace. It seems quite uncommon for large software frameworks to reference their product name so often in surface API, wouldn't you agree?
Another example would be the classes around AvaloniaObject. They basically serve the same purpose as the classes around DependencyObject in other XAML frameworks (the API is almost identical), yet they diverge from established naming, which makes it harder for new developers to intuitively understand their purpose.
Jeremy Koritzinsky
@jkoritzinsky
Jan 03 05:31
Part of the reason that they diverge is that in some areas their APIs are wildly different. Like our binding API surface on AvaloniaObject is very different from the WPF equivalent because our binding implementation is also very different.
Once you hit the Visuals layer, then everything in that layer and onwards matches name because they're similar.
I think it would cause more confusion to have object with similar concepts but drastically different API surfaces and different behaviors but the same name.
Steven Kirk
@grokys
Jan 03 11:09
yeah and it's not like the word "dependency" really tells you a lot about what the class does
as for AvaloniaList i considered NotifyingList but didn't really like that either
ObservableList is not a good name because that suggests rx
naming is hard
Benedikt Schroeder
@Gillibald
Jan 03 11:52
Yes good naming is not an easy task. Also very time consuming.
Benedikt Schroeder
@Gillibald
Jan 03 12:13
Any idea how we can transition to the next skia text layout smoothly? I am a bit scared that things will break in some situations. Writing unit tests for the TextBox interaction is a pain.
Any idea why font size is part of a Typeface?
ahopper
@ahopper
Jan 03 12:26
@Gillibald do shout anytime you think it is ready to test, btw I think I have just experienced AvaloniaUI/Avalonia#1625 with updating right aligned text ( not tried with your pr yet)
Jonathan
@vanillajonathan
Jan 03 12:32
Should Avalonia projects use WpfAnalyzers or have an own AvaloniaAnalyzers package?
Benedikt Schroeder
@Gillibald
Jan 03 13:51
Every time I think I am ready for testing I find some corner case that isn't working and have to refactor things. The whole layout has evolved a lot. Currently I focus on features and will work on performance later. Current performance should be okay but haven't done any testing to prove.
ahopper
@ahopper
Jan 03 14:00
ok, I have just created what could be quite a good performance workout, I've added some more modes to my radio program and at times it can have 100+ textblocks showing live conversations. It would be greatly improved with inlines to color callsigns etc.
ksigne
@ksigne
Jan 03 14:15
@here can anyone explain idea behind validation in AvaloniaProperty
it looks like just coercion function
Steven Kirk
@grokys
Jan 03 15:05
@ksigne it's combined validation/coercion. if the value is invalid you throw an exception
ksigne
@ksigne
Jan 03 15:44
@grokys but it just breaks execution thread
so if you have two objects
and making binding like that o1[!p] = o2[!p]
how can you intercept validation event?
Steven Kirk
@grokys
Jan 03 15:53
how do you do that in WPF/UWP?
afaik WPF throws an exception when an invalid value is produced by a binding too
ksigne
@ksigne
Jan 03 15:57
in WPF validation is binding property, not DependencyProperty..
and it sets attached property HasError on object that appeared to be non-validated
so it is basically a mixin not a property metadata
Steven Kirk
@grokys
Jan 03 16:04
are you sure you're talking about the same thing? it sounds like you're talking about data validation in WPF - the validation callback you're talking about is our equivalent of dependency property validation: https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/dependency-property-callbacks-and-validation#validation-callbacks
If the validation callback is invoked by any of these operations, and returns false, then an exception will be raised. Application writers must be prepared to handle these exceptions.
ahopper
@ahopper
Jan 03 16:16
anybody got any clues as to why d2d render tests fail on CI here AvaloniaUI/Avalonia#2211 but run fine locally?
Steven Kirk
@grokys
Jan 03 16:17
not sure @ahopper - let me re-run
ahopper
@ahopper
Jan 03 16:18
cheers
Benedikt Schroeder
@Gillibald
Jan 03 16:21
There should only be one factory hmm
@ahopper If you only display text you could try the current state of the PR with your app. Will let you know when the PR is in its final state.
ahopper
@ahopper
Jan 03 16:28
@Gillibald will try in the next day or so, thanks.
test now passed, is this an indication of a hidden occasional bug or just CI oddness?
mstr2
@mstr2
Jan 03 16:35
Is the issue where reading an inherited value requires walking the logical tree still considered relevant?
If it is, I might be able to contribute a PR.
ksigne
@ksigne
Jan 03 16:37
@mstr2 what do you propose? instantiate a binding?
mstr2
@mstr2
Jan 03 16:38
Store a soft reference to the
ksigne
@ksigne
Jan 03 16:38
reference to what?
mstr2
@mstr2
Jan 03 16:38
current value. If another value is inserted up the logical tree, invalidate that reference si that it needs to be recreated the next time the value is read.
ksigne
@ksigne
Jan 03 16:39
so basically it is a binding
mstr2
@mstr2
Jan 03 16:39
Yes, kind of. Needs to be very fast in order to not make things worse.
ksigne
@ksigne
Jan 03 16:40
do you realize that you can detach the whole branch from tree?
so you have to propagate invalidation info on whole branch each time you change parent
mstr2
@mstr2
Jan 03 16:44
Iā€™m not thinking about notifications here. On each downstream value that gets its value from inheritance, a serial value could be stored. A similar serial value would be stored on the authoritative upstream value, and incremented whenever the value is changed. If the downstream value is read, both serials are compared, and if they are different, the new value must be queried by walking up the logical tree.
It also means that if somewhere in the middle a value is set to a property, the serial on the next upstream value must be incremented, so that downstream values realize they have a new authoritative value source.
ksigne
@ksigne
Jan 03 16:49
So instead of walking up whole tree, you walking single step up, checking if synchro tag is not changed, and then use cached value.
So, if you have long tree with big height n you have 2 read operation instead of n. But if you have root value updated frequently you'll have 2n-1 operations instead of n
ahopper
@ahopper
Jan 03 16:55
I think it is a possibly a bit early in the optimization process to spend much time on optimizing the property system. Only once the actual number of calls to it have been optimized (reduced) and you know real read to write ratios, likelyhood of tree walking etc can you make optimal choices for data structures. For example with the current tree walking a value store with better performance for misses would be better but if the amount of tree walking changes, maybe not so. A fun problem though and the more ideas the better.
mstr2
@mstr2
Jan 03 16:57
Where is the 2n-1 coming from? If the root value is updated frequently, I think it would be one step up to see if the serials match. Since they won't, the next thing would be n steps upwards.
ksigne
@ksigne
Jan 03 16:57
You're so wasteful with memory, assuming the original WPF system was designed to reuse values..
@mstr2 you'll have two calls, first to compare tags, second to check for next value
mstr2
@mstr2
Jan 03 17:02
I see, but the tag would probably be stored alongside the value, so it's not two unrelated read operations.
ksigne
@ksigne
Jan 03 17:03
but there's still n tag comparisons on the tree?
Benedikt Schroeder
@Gillibald
Jan 03 17:03
Somehow a new / different factory is used. Maybe the render platform is initialized multiple times.
ksigne
@ksigne
Jan 03 17:03
@Gillibald look, in AvaloniaXamlType.cs
value = SetterValueTypeConverter.ConvertSetterValue(null, Member.DeclaringType.SchemaContext, CultureInfo.InvariantCulture, instance as Setter, value);
so context is set to null
explicitly
@kekekeks this is a line by you
ahopper
@ahopper
Jan 03 17:09
@Gillibald do you have the error still or a link back to it, I was going to open an issue just to log it
found it
ksigne
@ksigne
Jan 03 17:16
@Gillibald it is possible to track ValueSerializerContext down to type converter, but I don't see real reasons to do that.
mstr2
@mstr2
Jan 03 17:18
@ksigne Yes there might be an additional conditional branch here and there, but that's insignificant if the value is already available in CPU cache.
I've suggested a change to the current implementation that increases cache locality and yields ~10% better performance on the ClearAndSetIntProperty benchmark (PR #2209)
My feeling is that similar improvements could be made on inherited value reads.
ahopper
@ahopper
Jan 03 17:23
@mstr2 I think this really needs benchmarking with representative data, you could compare with profiling results used here AvaloniaUI/Avalonia#2127
or create a test that better represents the current usage with lots of tree walking misses
mstr2
@mstr2
Jan 03 17:25
How can I recreate the tests used in PR #2127 ?
ahopper
@ahopper
Jan 03 17:28
I forget which profiler @grokys uses but you can come close with the vs one and use the calender page in control catalog
or instument the calls to value store on loading the calender page and use that to create a test set
ksigne
@ksigne
Jan 03 17:38
@Gillibald @grokys @kekekeks Portable.Xaml does not pass writer context to derived member setters
and member setter container is a singleton
so you either change Portable.Xaml interface, either instantiate member setter containers on each load
ksigne
@ksigne
Jan 03 19:42
@Gillibald well, I was able to solve the problem with Setter and context
Benedikt Schroeder
@Gillibald
Jan 03 19:49
@ksigne šŸ‘
ksigne
@ksigne
Jan 03 20:40
#2185.url