Windowscommunitytoolkit: Lag on the quickreturnheader

[karmaecrivain94]

There's a noticeable lag on the QuickReturnHeader: The movement of the header and the scrolling isn't very tightly synchronized, as, especially when scrolling up, the header seems to lag behind. There's also often a pixel wide gap at the top of the header.

It may seem superficial, but details like this have a big impact on how polished an app feels. Could someone reading this from msft ask how the Groove Music team achieved the same effect?

[deltakosh]

I'm not sure to see this lag.. Can you capture a video to be sure we are talking about the same thing?

[JohnnyWestlake]

If this only when using the scrollbar on desktop, or also with touch?

[lukasf]

I also noticed that the control lags quite a lot in quick return mode. To me it happens when scrolling with touch pad gestures. Much like the OP my first thought was, I would not use this in an app. It looks very unprofessional with this kind of lag.

The problem is that in quick return mode, the header position is updated manually on each scroll step, based on the ScrollViewer.ViewChanged event. This causes a delay because things are not done purely in Composition. I guess it might be possible to get a smooth behavior with an improved Composition approach. Most of the calculations that are currently done manually in ViewChanged could be integrated into the CompositionAnimation. We'd still need the ViewChanged event, but a property update in the AnimationPropertySet would only be done if the actual quick return position changes. But this Composition stuff is really complicated, not sure if I can do it.

[lukasf]

Well, after playing a bit with the control, I now have an improved version that is totally lag free, it runs butter smooth here! Right now I have a different PR in the making. But once that is finished, I can submit a fix for this!

[lukasf]

I just created a PR for solving this!