How to speed up opening drawer host in Material Design in xaml toolkit?

[VahidEra]

Hi guys,
I have a drawer host in my WPF project and I want to increase its opening speed because by default its opening speed is slow. Is there any chance to increase its opening speed?

This is my cod:

      <materialDesign:DrawerHost 
            OpenMode="Modal"
            x:Name                    ="draPlaylist" 
            IsRightDrawerOpen          ="{Binding DrawerOpen}"   
            RightDrawerBackground       ="White"         
            RightDrawerCloseOnClickAway ="True" 
            Foreground                ="Black" 
            RenderTransformOrigin     ="0.5,0.5" Margin="0,0,-1,-1">
            <materialDesign:DrawerHost.RightDrawerContent>
                <Grid>
                    <Grid.RowDefinitions>
                        <RowDefinition Height="Auto"/>
                        <RowDefinition Height="Auto"/>
                    </Grid.RowDefinitions>
                <StackPanel
                    Grid.Row="0"
                    Width="200"                   
                    x:Name="stPlaylist">
                </StackPanel>
                </Grid>
            </materialDesign:DrawerHost.RightDrawerContent>
        </materialDesign:DrawerHost>

I have no idea how to do this.

[nicolaihenriksen]

@VahidEra I think you will have a hard time increasing the speed of the animation without having to write a lot of stuff on your own. The animations are defined in Generic.xaml (the linked example shows the left drawer).

You do have the option to disable the animation though. You can do that by setting TransitionAssist.DisableTransitions="True" on your DrawerHost. This is an inherited attached property, so you may want to enable it again on a child element if you want transitions inside of your drawer.

[VahidEra]

@nicolaihenriksen Dear friend,
You are absolutely right and as always you answered my question completely and flawlessly. I wish Material Design would provide more options to the programmer so that he could meet his needs without manipulating the original code. :-)

[nicolaihenriksen]

@nicolaihenriksen Dear friend, You are absolutely right and as always you answered my question completely and flawlessly. I wish Material Design would provide more options to the programmer so that he could meet his needs without manipulating the original code. :-)

I believe the intention to expose properties to give the user a lot of control is definitely there. And creating a discussion topic or an issue in the repository is definitely a good way to indicate the desire for something which might be missing.

Having an option to control the duration of this animation could be a relevant addition. However, if I remember correctly, I believe binding to an attached property (which is how we typically expose hooks) from within a storyboard transition is problematic; typically it throws a binding error like "Cannot find governing FrameworkElement or FrameworkContentElement for target element". @Keboo do you have any great ideas on how to expose such a duration for the user to manipulate it? I guess it should also be considered whether it is a "global transition duration" similar to TransitionAssist.DisableTransitions, or there should be hooks for all the different animations in the library (whoa, that could be quite a big task)...

[Keboo]

Yea the storyboards and bindings don't really work.
From the docs

You can't use dynamic resource references or data binding expressions to set Storyboard or animation property values. That's because everything inside a Style must be thread-safe, and the timing system must FreezeStoryboard objects to make them thread-safe. A Storyboard cannot be frozen if it or its child timelines contain dynamic resource references or data binding expressions.

It also gets complicated since we probably want to expose a simple API like TimeSpan but many of the target properties will need to be converted to various other target types.

Though in this case I think we have some options.

When doing the bindings

Another thought I have would be to make static properties that could be set in code (likely need a new class to hold them). This would allow a measure of configuration, but it would, at best, be a per-style level configuration (you would not be able to change it for a single instance of a control). This might be good enough for most people, as I suspect if you are modifying the durations, you likely don't need (or want) different durations per instance.
It would end up looking something like this (this is just a proof of concept, I am not sure I like the API).


Then to change the animation speed, consumers could do something like this in their own app.

The big drawbacks I see with this approach are:

1. Set once per-style, can't change per-instance
2. Nested styles may be problematic and cause un-intended consequences. Imaging the ripple animation, and wanting different speeds for the one in the button vs a checkbox.

Another option we could consider is exposing extension methods on the control types that really just handle the lookup that a caller could do today. Something like this:

This approach would give per-instance level control, but it comes with a bunch of negatives:

1. Pain to invoke correctly. Because it relies on looking up the visual states it needs to be called in a Loaded event handler or similar timing. We might be able to smooth over some of this is a behavior or similar.
2. Must be called form code. Again, we might be able to do something fancy with a behavior (maybe put some logic in the on-changed of an attached property or similar) to try and provide a nicer interface, but still not great.
3. Bit of a pain to maintain, though with some of the source generation work I want to do for 5.x perhaps we could generate it?

Other thoughts people have?

[nicolaihenriksen]

@Keboo Thanks for the input!

The approach with the static properties, to me, seems like the better of the two options. I feel the second option creates an even tighter coupling between the assist-class and the XAML than we had before; The assist-class now needs to have implementation knowledge about the storyboards, transitions, etc. from the corresponding XAML.

For your second bullet in the static properties approach: Perhaps this could be partly mitigated by adding the RippleAnimationTime on the context-specific assist types rather than RippleAssist. I know this is not the way we "normally do it today", but having a ButtonAssist.RippleAnimationTime, CheckBoxAssist.RippleAnimationTime, etc. would be one way to get around this?! It would still be a once-per style, but you would have a little more flexibility