Value store v3.0 #8600
Value store v3.0 #8600
Conversation
Most (but not all) tests passing, all features mostly implemented exception coercion.
To remove `InheritanceFrame` - it was unneeded, we can just point to the nearest ancestor value store with inherited values.
With associated unit tests.
- Always evaluate the active state from current information, don't rely on subscriptions to fire as the current state may not be up-to-date - Don't notify the `IStyleActivatorSink` of a change immediately on subscription
And use the concrete `ValueFrame` (renamed from `ValueFrameBase`) as this was the only implementation of the interface.
If a `StyleBase` has no activator, and its `Setter`s don't need to be separately instanced on the control, then we can share a `StyleInstance` between controls. This causes failing tests because `TopLevel` applies styles in its constructor, but doesn't set `_styled` to true, meaning that styles get applied twice. This issue will need to be addressed separately.
Due to #8549.
And rename collection to indicate this.
|
You can test this PR using the following package version. |
| target.StyleApplied(instance); | ||
| instance.Start(); | ||
| if (target is not AvaloniaObject ao) | ||
| throw new InvalidOperationException("Styles can only be applied to AvaloniaObjects."); |
There was a problem hiding this comment.
Due to GH formatting this almost looks like as it happens all the time. Maybe adding braces here wouln't hurt.
There was a problem hiding this comment.
Not sure what you mean here?
Added `IValueEntry<T>` interface back in and use that if present to get the value from the entry.
|
You can test this PR using the following package version. |
Decreases the number of metadata lookups needed. Previously we were doing two lookups on construction now we're only doing one.
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
What does the pull request do?
This PR implements a new value store for
AvaloniaObject. Previously, each property value was stored in a dictionary insideValueStorewhich mappedproperty->value, wherevaluechanged type depending on what was stored (single local value, single binding, multiple values of differing priorities).This PR changes
ValueStoreto store property values in a different manner;EffectiveValue<T>containing the effective value and base value + prioritiesEffectiveValue<T>for the propertyImmediateValueFrame: values set bySetValueorAddBindingwith non-LocalValue priority.StyleInstance: a frame containing theSetters for a styleIValueEntrysSome improvements the new value store enables:
ValueStores meaning thatStyles which don't have activators (andControlThemes) can be instanced just once instead of needing to be instanced on eachAvaloniaObjectseparately.Setteris anIValueEntrymeaning that it can be stored directly a frame unless it needs to be explicitly instanced on each controlControlThemecan be changed without affecting the rest of the styles applied to it (this isn't actually implemented yet - will require a change to ourBindingPrioritys in order to distinguish between control themes and styles)LocalValuestyled property bindings, removing the need for 2 lists perAvaloniaObjectBenchmarks
Of these,
InitializeButtonis only 26ns slower which is on the limit of what can be measured.The nearly 19x improvement in reading inherited values should really make a difference in some applications.
Memory benchmarks have now been added. Most of increases in memory are because of the particular scenarios the benchmarks are testing and should be offset by the decreases in a real app.
Breaking Changes
Removes
BeginBatchUpdate/EndBatchUpdateand replaces it with internalBeginStyling/EndStylingas the current batch update system introduced in 0.10.1 isn't zero cost, whereas the more limitedBeginStyling/EndStylingis.I want to re-think and maybe re-implement batch updates separately from this PR, at least for initialization, but if anyone is using them please let me know how/where.
Depends on #8571