Bug 58048 - AspectFill behaves differently with Android.FastRenderers.ImageRenderer
Summary: AspectFill behaves differently with Android.FastRenderers.ImageRenderer
Alias: None
Product: Forms
Classification: Xamarin
Component: Android ()
Version: 2.3.5
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2017-07-10 14:53 UTC by Matthew Richardson
Modified: 2018-02-20 23:15 UTC (History)
7 users (show)

Tags: ac android image stacklayout isclippedtobounds fastrenderer
Is this bug a regression?: Yes
Last known good build:

Screenshot showing XF 2.3.4 vs 2.3.5 (150.67 KB, image/jpeg)
2017-07-10 15:02 UTC, Matthew Richardson
Repro Project XF 2.3.4 (115.93 KB, application/zip)
2017-07-10 15:03 UTC, Matthew Richardson
Repro Project XF 2.3.5 (115.98 KB, application/zip)
2017-07-10 15:03 UTC, Matthew Richardson
Master (989.04 KB, image/png)
2017-11-09 23:35 UTC, Chris King

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Matthew Richardson 2017-07-10 14:53:24 UTC
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.
Comment 1 Matthew Richardson 2017-07-10 15:02:15 UTC
Created attachment 23451 [details]
Screenshot showing XF 2.3.4 vs 2.3.5
Comment 2 Matthew Richardson 2017-07-10 15:03:18 UTC
Created attachment 23452 [details]
Repro Project XF 2.3.4

Comment 3 Matthew Richardson 2017-07-10 15:03:37 UTC
Created attachment 23453 [details]
Repro Project XF 2.3.5

Comment 4 Jimmy [MSFT] 2017-07-10 21:14:00 UTC
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   BAD
2.3.5-pre6  BAD   GOOD
Comment 5 Matthew Richardson 2017-07-11 07:50:45 UTC
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.
Comment 6 Britton Beckham 2017-07-14 19:49:37 UTC
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?
Comment 7 Chris King 2017-11-09 23:35:22 UTC
Created attachment 25624 [details]

This issue no longer reproduces on the latest version of XF.
Comment 8 PaulD 2017-11-30 15:20:45 UTC
I can reproduce this issue on specific android screen with 420dpi and 560dpi.

Default DPIs like (L M H XH XXH) work fine.