-
Notifications
You must be signed in to change notification settings - Fork 710
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ScrollViewer v2 bugs/missing functionality compared to the platform ScrollViewer #829
Comments
This is great feedback, thanks! |
…dth or ExtentHeight is incorrect when Content stretches partially.
* Fixing Scroller layout bug mentioned in Issue #829: Scroller.ExtentWidth or ExtentHeight is incorrect when Content stretches partially. * Using lambdas in Scroller::ArrangeOverride.
@RBrid I can confirm that that the third issue is now solved (Thank you!), but I still have issues with the ScrollTo() and ZoomTo() methods. I basically want to zoom to an selection rectangle drawn with the mouse. With the platform scrollviewer, I can just calculate the required zoom level and offset by registering the pointer event handlers on the xaml element and transforming the received coordinates to the parent viewbox. Then a single call to ChangeView() is sufficient to end up at the right position and zoom level. With the winui scrollviewer I have to use a combination of ZoomTo() (with null as the center point), followed by a ScrollTo(). This works fine in most cases but sometimes the transition does not seem smooth (i.e. I see a jump after the zoom operation). The same issue is apparent when reseting the view again (i.e. going to position 0,0 and zoom level 1). It seems that the mismatch of the aspect ratios still causes issues during the animation. |
Thank you @lhak. Maybe you are seeing issues with combining ScrollTo/ZoomTo calls because this PR #972 still needs to be merged with master. Anyways, regarding the ChangeView method, I just wrote a little utility method in C# that in many cases simulates the behavior of the old ScrollViewer.ChangeView method. It uses its exact signature and triggers a single call the ScrollTo or ZoomTo. I hope this helps.
|
Nice, the snippet could go into the docs (@micahl). |
@RBrid Thank you for the code. Unfortunately, when using it in the scenario above, different aspect ratios of the scrollviewer viewport and the xaml element still lead to an incorrect final position after zooming in to a certain region. |
@lhak, if you provide me with a little repro application or code & instructions to repro the issue, I can investigate. Thank you. |
@RBrid, I tried using the snippet you provided in my app, and I still have the problem I reported in #937 even though it does only one method call, here: https://github.com/adrientetar/Fonte/blob/dd9ff616458b375f3c697194cb4e5aa110cdc246/Fonte.App/Controls/DesignCanvas.xaml.cs#L353-L357 |
@RBrid I have attached a sample application that shows this issue below. Make sure the window width is larger than the rectangle with the gradient, then left-click to zoom in. The upper left of the view should correspond to the position of the click after the zoom operation. This works well with a combination of ZoomTo()/ScrollTo() calls, but the animation is not smooth. Using your sample code seems to result in an incorrect final position. A right-click will reset the scrollviewer (please note the jump during the animation). You can also change to the platform scrollviewer in the XAML file by removing the namespace prefix and uncomment the calls to its ChangeView() methods in the code. As you can see, zooming in and out works fine in this case with smooth animations. |
Thanks much @adrientetar and @lhak, this is really helpful. @lhak, I ran your little app and quickly realized that the code snippet I provided last Friday had a bug in its centerPoint evaluation. In particular, it was wrong when the content was smaller than the viewport. You will see below that the new centerPoint evaluation is a bit more complex now. Secondly, if you clicked close to the right and bottom edges of the Rectangle, you would attempt to animate beyond valid offsets. In your case, you probably prefer to systematically clamp the target offsets, so I commented out the 'if (disableAnimation)' line below for you.
@adrientetar, I have not looked at your scenario yet. If it is still broken after these updates, I will investigate further. Thanks. |
@RBrid Thank you very much for the code. I added it to my application and it is working great with smooth animations. I actually clamp the rectangle for the zoom operation to valid values in my application so I could remove the code in the if(disableAnimation) block. |
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
Still relevant |
Describe the bug
I was asked to list the missing features and bugs that the winui ScrollViewer has compared to the platform ScrollViewer
Steps to reproduce the bug
Use some XAML code like this:
These are the regressions:
Missing: ViewportWidth and ViewportHeight are not bindable and so extra code behind is required
Missing: ChangeView() method to set the position and zoom at the same time
Broken: The Viewbox handles aspect ratio differences between the scrollviewer and the element by adding empty space at the borders. This empty space is still present when zooming in (and the element is now larger than the scrollviewer in all dimensions). The platform scrollviewer handles this correctly.
Broken: The ScrollTo() method always scrolls to the wrong position in the scenario above. Same seems to be true for the ZoomTo() method if a center point is specified.
Missing: CanContentRenderOutsideBounds property and the related functionality
Expected behavior
ScrollViewer should have parity with the platform ScrollViewer
Screenshots
Version Info
NuGet package version:
Additional context
The text was updated successfully, but these errors were encountered: