Ffimageloading: [XF] Something wrong with CachedImage.AspectFill in 2.2.25 with 420dpi in Android

[JTOne123]

After updating from 2.2.20 to 2.2.25, I've occurred an issue with AspectFill at 420dpi (it's Nexus 5X), I guess, something wrong with clipping of image.

Also, I've checked 560dpi and the same issue found.

Typical dpi like l,m,h,xx works fine
I've tested it on Android 5, 6, 8

The image was not clipped and fill the bottom margin and placed under neighboring image

The correct one, the image was clipped and we can see the bottom margin

[daniel-luberda]

It's not FFImageLoading but Xamarin.Forms issue when fast image renderers are used. You can disable fast renderer with CachedImageRenderer(false). Did you try it?

[JTOne123]

Yes, it is fastrenderers

Thank you for the hint, how I can disable it.

---

What do you think about this workaround?

            var supportedFastRenderersDpi = new[] {
                DisplayMetricsDensity.Default,
                DisplayMetricsDensity.Low,
                DisplayMetricsDensity.Medium,
                DisplayMetricsDensity.High,
                DisplayMetricsDensity.Xhigh,
                DisplayMetricsDensity.Xxhigh,
                DisplayMetricsDensity.Xxxhigh
            };            

CachedImageRenderer.Init(supportedFastRenderersDpi.Contains(Resources.DisplayMetrics.DensityDpi));

Is it crazy?

[daniel-luberda]

You can disable fast renderer with CachedImageRenderer(false)

Is it crazy?

It's Xamarin.Forms issue, it should be fixed IMO. I don't know if there's a Xamarin.Forms bugzilla entry for that. Maybe they have some workarounds for that :)

[daniel-luberda]

When you replace CachedImage with Image (with fast renderers flag) the same behaviour exists:)

[JTOne123]

Did you see the issue about that in xbugzilla? Maybe we need to create it?

[daniel-luberda]

I didn't time to do it yet. It would be great if you could create it. There are similar issue here:

• https://github.com/luberda-molinet/FFImageLoading/issues/824
• https://github.com/luberda-molinet/FFImageLoading/issues/824#issuecomment-346177328

[JTOne123]

I guess I have found this issue on xbugzilla

https://bugzilla.xamarin.com/show_bug.cgi?id=58048

[daniel-luberda]

Status: | RESOLVED FIXED

Nice catch! Looks like it should be reopened.

[daniel-luberda]

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).

[JTOne123]

yes, I need time to try and delete my super duper cool workaround :)

[JTOne123]

Yes, it helps. This workaround is much better :)

[Nico04]

Unfortunately I can reproduce this old issue with all latest packages installed (XF v3.0 & FFImageLoading v2.4.1) : With AspectFill, on Android, image is not cropped (but on some cases, with same image, it actually work...)
My current workaround is to embed it in a Frame with IsClippedToBounds=true.

[daniel-luberda]

@Nico04 Could you make repo so I could fix it?

[Nico04]

Unfortunately my code is private, but I'll make a small project trying to reproduce the issue soon, thanks.

[Nico04]

I've build a sample project to show and test the bug :
https://github.com/Nico04/FFImageLoadingSample

I've tried several cases, some work and some don't.
Case that doesn't work :
1/ FFImageLoading in a SfListView (SyncFusion ListView component)

Cases that work great :
A/ FFImageLoading in a ListView (Xamarin.Forms component)
B/ Image (Xamarin) in a SfListView
C/ FFImageLoading in a Frame in a SfListView

So the problem is an association of FFImageLoading & SfListView.

Do you have any idea ?
I've sent this message to the SyncFusion team too :
https://www.syncfusion.com/forums/138132/sflistview-amp-ffimageloading-height-problem

[daniel-luberda]

Do you use fast renderer? (CachedImageRenderer.Init param)

[Yuvaraj-007]

Hi Nico04,

I think the following workaround is working fine for you. Can you check this.

public class MainActivity : global::Xamarin.Forms.Platform.Android.FormsAppCompatActivity 
{ 
    protected override void OnCreate(Bundle bundle) 
    { 
        TabLayoutResource = Resource.Layout.Tabbar; 
        ToolbarResource = Resource.Layout.Toolbar; 

        base.OnCreate(bundle); 

        FFImageLoading.Forms.Platform.CachedImageRenderer.Init(false);

        global::Xamarin.Forms.Forms.Init(this, bundle); 
        LoadApplication(new App()); 
    } 
} 

[Nico04]

Yes I use fast renderer, setting this to false will not impact performances ? If so, I think I would prefer the "Frame" fix no ?

[Yuvaraj-007]

I didn't accurately know it is affect performance or not, But I checked the sample working fine for this workaround. If use fast renderer then pass argument as false to skip the image height problem.
FFImageLoading.Forms.Platform.CachedImageRenderer.Init(false);

[Nico04]

Hello,

Thank you for your answer.
Unfortunately what you provide is a workaround that lower performances (which is still great though), not a fix nor a real solution.

Do you have an idea on a solution ?
I've told the same to the SF team, maybe it's on their side...

Thanks.

[daniel-luberda]

Fast renderers are not enabled by default in Xamarin.Forms. You must explicitly enable it with Forms.SetFlags("FastRenderers_Experimental"); - so maybe SF Team doesn't test their controls with fast renderers? It may be also a XF fast renderer bug too. I don't think it's related to FFImageLoading.

[Nico04]

Nice to know, I didn't know it was an experimental feature.
So I will wait until it is stable. Thanks !