AspectFill behavior is different on XF 2.3.5 vs XF 2.3.4 when using an image in a nested view hierarchy.
Under certain conditions, the image is not cropped correctly to fit the bounds of its container and instead overlaps in the case of multiple images in a vertical layout.
See repro projects XF 2.3.4 vs XF 2.3.5 and screenshot showing difference.
Note: Using IsClippedToBounds="true" on a nested StackLayout in the demo project resolves the problem, but this was not required before XF 2.3.5 and don't want to assume this is a fix (may be a workaround).
Possibly without the parent ViewGroup with the new fast ImageRenderer on Android, the scale behavior has been changed.
Created attachment 23451 [details]
Screenshot showing XF 2.3.4 vs 2.3.5
Created attachment 23452 [details]
Repro Project XF 2.3.4
Created attachment 23453 [details]
Repro Project XF 2.3.5
I'm seeing the issue described using the attached repro projects and this does appear to be a regression in 2.3.5.
The images appear to be scaled correctly, they are just not being clipped. As mentioned, using IsClippedToBounds="true" on the inner StackLayout resolves the issue. I tested the same layout replacing the AbsoluteLayout with a RelativeLayout and the issue still occurred.
I also tested the old ImageRenderer and confirmed that the issues does _not_ occur in that case. So another workaround is to use the old renderer by exporting it like a custom renderer:
> [assembly:ExportRenderer(typeof(Xamarin.Forms.Image), typeof(Xamarin.Forms.Platform.Android.ImageRenderer))]
### Version Tests
Jimmy - I wonder if the clipping behavior was happening implicitly due to the nesting of the image view inside a view group? So 'technically' now it is behaving as expected, but the behavior is not desirable.
I was getting this same thing, but in a GridLayout. Shouldn't this be considered a breaking change if it is technically correct, even though it was wrong in the first place?
Created attachment 25624 [details]
This issue no longer reproduces on the latest version of XF.
I can reproduce this issue on specific android screen with 420dpi and 560dpi.
Default DPIs like (L M H XH XXH) work fine.