RotatorTile fix for flickering

[nmetulev]

Issue: #1597 and #1411

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build or CI related changes
[ ] Documentation content changes
[ ] Sample app changes
[ ] Other... Please describe:

What is the current behavior?

See issues #1597 and #1411

PR Checklist

Please check if your PR fulfills the following requirements:

• Tested code with current supported SDKs

What is the new behavior?

The RotatorTile no longer flickers

Does this PR introduce a breaking change?

[ ] Yes
[x] No

[michael-hawker]

Would it be better to use the dispatcher here to queue up in the UI thread for processing?

[nmetulev]

Tried that, it didn't have an effect at all :(

[michael-hawker]

Normal or Low priority?

If we need to keep this delay, we should subtract it from the rotation time, eh?

[nmetulev]

Good point, only tried normal, let me try low. On the subtraction, don't think it's needed as it's random anyway

[nmetulev]

Yeah, even low priority doesn't help :(

[michael-hawker]

Bummer, that's frustrating. I know Idle usually causes bad things in UWP land.

For the timing though, it's only random is the ExtraRandomDuration is non-zero. Otherwise, it's fixed, so we would want to subtract the Delay time (as a const) from the base RotationDelay.

We should probably clarify in the doc comments for the property too that there's a minimum delay.

[azchohfi]

Go for it and we should be good!

[nmetulev]

The Task.Delay doesn't really add any timing to the duration, it happens in parallel. When the rotation completes (after the duration) it just waits 50ms before switching the two items. The duration is not affect by this at all.

I did add a quick snippet about the duration in the documentation though.

[windowstoolkitbot]

This PR is linked to unclosed issues. Please check if one of these issues should be closed: #1411, #1597