Unwanted transition effect in control being virtualized in a virtualizing panel

[msneijders]

For context: I am building a virtualized treeview using TreeDataGrid -- but could be in any control that is virtualizing its contents.

To fancy up the tree view item, I animate the chevron when the user toggles it. Imo those small animations in a UI can help the user to see what is happening.

Currently I do this in my ControlTheme for a ToggleButton, using a simple transform transition using RenderTransform:

<ControlTheme x:Key="ToggleButton/Theme/TreeExpander" TargetType="ToggleButton">
    <Setter Property="Template">
        <ControlTemplate>
            <Border>
                <Path x:Name="ChevronPath" Data="{StaticResource Icons/Chevron_right/Geometry}">
                    <Path.Transitions>
                        <Transitions>
                            <TransformOperationsTransition
                                Easing="CircularEaseInOut"
                                Property="RenderTransform"
                                Duration="0:0:0.15" />
                        </Transitions>
                    </Path.Transitions>
                </Path>
            </Border>
        </ControlTemplate>
    </Setter>
    <Style Selector="^:checked /template/ Path#ChevronPath">
        <Setter Property="RenderTransform" Value="rotate(90deg)" />
    </Style>
</ControlTheme>

Problem with this solution: Whenever a control using a transition effect like this gets realized by a virtualizing panel, usually when an item gets scrolled into view, this effect can be triggered and in this case the chevron will animate:

Question: Does anyone know a solution for a) keeping it simple to add small animations like this, but b) not letting it triggered in a container control that is virtualizing it?

[stevemonaco]

I suspect there's a solution to add Transitions on either Loaded or AttachedToVisualTree so initialization activity doesn't trigger transitions. You'll also need to remove them. This can be made a bit more handily with a custom attached properties.

Either way, I can't get reproduce this behavior in either ItemsControl (with parent scroller and VirtualizingStackPanel) or with ListBox using Avalonia 11.2.3 on Windows. Though I think this behavior still happens in places.

[msneijders]

I think by default the ItemsControl removes the Content of the recycled container during the "Clearing"; and its the content that contains the transition. And during preparing that content (and the transition) is added back into it. This way of recycling might prevent the transition problems.

In my app for Android, I had to replace this default behavior, and I keep the content in the container -- the layout time it needed was reduced by half, which was really needed to get some decent scrolling performance.

So the specific way of recycling influences the behavior of transitions. TreeDataGrid must be doing it differently by default -- I have not tested DataGrid yet.

[timunie]

Guess you need to remove the animation. I've a similar issue for ToggleSwitches

[msneijders]

I do have a working solution, but I feel it is quite the hack, could have perf problems, and needs a different implementation depending on the specific virtualizing panel being used:

Both TreeDataGrid and VirtualizingStackPanel (or rather ItemsControl) raises events for when a control gets "prepared" for recycling, and also when it is "cleared", removed from virtualizing.

Now when a control gets "cleared" I perform a "RemoveTransitions()" on that control -- it walks over the entire visual tree of that control, removes visual.Transitions, and holds on to those transitions.

When a control gets "prepared" (so it is fully prepared, all its properties are set to the new virtualized item), I perform a "RestoreTransitions()" on it, restoring all the transitions from the previous step.

--

I am wondering if "recycling" of controls/visuals in the context of virtualizing could become a concept within the avalonia framework itself -- handling problems around it more efficiently and more standardized.

[stevemonaco]

You can probably create a new container type (ie. ListBoxItem alternative) that handles content changing a bit smarter. Then create a new collection control (ie. ListBox alternative) that overrides NeedsContainerOverride and CreateContainerForItemOverride. PrepareContainerForItemOverride and ClearContainerForItemOverride are also available. This should be enough for VirtualizingPanel and ItemContainerGenerator to work with.

I don't think pushing this much into the DIY-realm is intuitive enough for a long-term solution for Avalonia though.

[msneijders]

This is indeed the way I have overridden the default logic of ItemsControl. This way I could optimize the recycling technique (basically by doing nothing to the container except changing its DataContext), and get some more performance for lower-end Android devices. This recycling technique however then leads to transitions problems -- which can be solved with the solution above triggered inside the Prepare and ClearContainer methods. This has been in production for a quite some time -- so your suggestion works.

But my point is exactly yours, it's quite some do-it-yourself right now -- which is fine in itself -- but tackling the transition problem outside of the avalonia framework feels limited right now. But also I am struggling to come up with a suggestion how the framework could help more.

[stevemonaco]

There could be a loading / recycling pseudoclasses applied similar to https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Controls/Mixins/PressedMixin.cs . Then write a style selector that only adds transitions when not recycling. Of course, with the mixin approach, you need to modify the control's source. Outside of Avalonia, we can only set pseudoclasses with attached behaviors/properties or code-behind. Mixins would probably be better for exposing lifecycle state as pseudoclasses as a built-in Avalonia feature.

This would add small, broad overhead though.