I have a framework element that I need to keep in view at all times. To do this, I am using BringIntoView() whenever it gets out of bounds. However, I have noticed that BringIntoView() does not handle rapidity very well. When the UI is manipulated in a rapid fashion (in my case it is a timeline containing a selector), BringIntoView() seems to not be able to keep up. When the selector in the timeline is moved quickly outside the bounds of the container, BringIntoView() will (seemingly) try to anticipate this rapidity by moving the selector very far from the bounds.
Instead of a smooth scrolling effect that takes place when the selector is moved slowly, instead what we get is a jittery scroll with the selector constantly going back and forth between being at the edge of the container and in the middle of it. It is almost as if it cannot handle the rapidity and gives up trying to make precise movements by just chucking the framework element as far away from the container boundaries as possible.
I have no idea how BringIntoView() works but I'd like something similar that can anticipate the distance that needs to be scrolled in comparison to the positioning of the framework element. Is there anything else similar to "BringIntoView()"?
After lots of searching I came upon this thread:
The solution to getting rid of the jittery/jumpy behavior in the slider had nothing to do with "BringIntoView()" at all but instead with the rapidity of the two-way value binding behind the control. Adding Delay=1 to the binding got rid of any jittery behavior in the control. It essentially adds a 1 millisecond delay to the two-way binding allowing time for the UI to update accordingly.
There is one tradeoff; the UI is not as smooth due to the 1 ms delay. But it's a tiny sacrifice, at least for me.