There is a very powerful library, FFImageLoading,, at : https://github.com/luberda-molinet/FFImageLoading
This one provide a lot of interesting features to manipulate images, mainly adding filters, smart caching , load/save file formats etc...
The idea is to make it part of Xamarin.Forms
I have tested this library, it is really powerful, but it need some improvements and maintenance.
Maybe some bug fixing too, of course, but 95% of the work is done and it can be very useful for
a lot of purposes.
We can create :
May I ask why this should be part of Xamarin.Forms instead of imported as desired?
@samhouts I agree with @vd3d
Not saying it should be FFLoading but something similar. Caching ,retry logic and more efficient memory usage on images should be standard in XF and not an extra that need to be implemented. Agree with his observation that pulling in this library should serve the community much better as this particular one needs way more resources than it currently has. More importantly there are no real alternatives that works cross platform and that is a problem. Perhaps a combination of Glide and FFLoading for true cross platform capabilities.
That's good feedback. We do intend to update image handling on Android to use GlideX (see https://github.com/xamarin/Xamarin.Forms/issues/3577), which should handle caching at a minimum.
In our recent Android project we have to switch from FFImageLoading to modified GlideX solution due to performance issues, especially on low-end devices. FFIL was allocating many .NET arrays during image loading, making UI laggy because garbage collection was happening too often.
I'm not in favor of this because a) FFImageLoading is not a small library b) baking it into Forms will discourage, in my opinion, the current maintainers of the library from continuing further work. The Forms team has lots on their plate and can't usually focus on a narrow subset of their own framework. I wouldn't want image processing to have the same fate. I'd, however, like to see @davidortinau and co to support the most popular 3rd party libraries in whatever way possible.
@dminta I could see how you've had allocation issues. Maybe @daniel-luberda can integrate some of that Glide candy into FFIL?
I don't say that we need FFImage to be part of XF, but that we need similar features, like caching, converting images as JPG/PNG, and filtering. It can be an extension of the Image/ImageSource.
For now, FFImage has some kind of duplicates and it has to be improved / tested / fixed more ! I can be useful for so much applications !
Also, look at WPF... BitmapEffect etc... are part of the core framework, it has to be the same in Xamarin ! Once the basic integration work is done (main features I mean), we will be able to integrate such effects in the framework too, if requested !
PS: Glide is Android only :-(
Also, I completely agree with @Pinox !
FFImageLoading is a great library! I don't anticipate trying to merge that in. It really stands on its own.
I would love to have a proposal on the improvements we can consider making to Image handling in Xamarin.Forms, both to adopt key features present in that lib, and to create an even better platform for FFImageLoading to build upon.
I understand, and yes it is a great lib and the author has do an amazing work, but still it remain a lot of issues and stuffs to improve ! It is not really maintained, even some samples are not working (at least on my side).
So, how to do a proposal ?
On my side, I see :
1 - Image filtering (effects, cropping, etc...), on the GPU (at least as fast as possible)
2 - Save as JPG/PNG
@vd3d With all the issues in Xamarin Forms, asking for the implementation and support of a library like FFImageLoading is far from being realistic.
I do not wish to be rude, I'm just expressing my thoughts how the reality is.
Also, look at WPF... BitmapEffect etc... are part of the core framework, it has to be the same in Xamarin ! Once the basic integration work is done (main features I mean), we will be able to integrate such effects in the framework too, if requested !
You definitely have a point here. I think it makes sense to have this in Xamarin Forms, but not by FFImage.
If you have a concrete list of features which exist in WPF/UWP, please create a proposal.
But please not like this: "instagram like filters" :) Instagram has a lot of filters, you can't really express all of those.
Caching ,retry logic and more efficient memory usage on images should be standard in XF
I agree with these features. Let's be clear in what we want, do you have a precise list?
No problem, you're not rude but realist ;-)
But so, then I see 2 points of view :
1) We already have a bunch of features in FFImage, but using it in production
can be problematic, because of performance and bugs/issues.
2) Ideally, Xamarin.Forms should support all theses features !
So, why not a progressive and mixed approach ?
To be pragmatic, it will be fine if MS can allocate some ressources on this project, in order to:
And progressively they can also check if it is possible to refactor it to mix it later with the Xamaxin.Forms API ! Maybe progressively moving some features into Xamarin.Forms and not everything in one step !
Because first, what we need is a set of features that are ready for production, that'as all ;-)
But I don't know if such way of working is possible of course ;-)
PS: It is just an idea :-P
To be pragmatic, it will be fine if MS can allocate some ressources on this project
You're still too confident, but I appreciate your enthusiasm 😄
Like David said, create a concrete set of features you'd like, my suggestion would be similar to what you find in UWP. That would be a great starting point.
Hi everyone. Disclosure - I'm an author
FFImageLoading is quite a complex library, I've spend a LOT of time on it implementing new features, improving performance and fixes. It's quite stable now, but there're a lot of things to improve. It's not easy if you do it only as a side project.
For example, currently I implemented a new way of handling SVG images which I use heavily in some of my projects (not using bitmaps anymore, large performance boost, uses a lot less memory while still using the same APIs) and because of that I didn't really have time to check on issues on project's site lastly. I always try to merge all PR's (BTW: many thanks to all of the collaborators!), but most of issues are like "could you tell me what's wrong" - and it's a really time consuming job to analyse and debug every case if you're alone with it :)
Internally, FFImageLoading does most of the things just the same as Glide library, with the difference that we do it on .NET side, so sometimes we have to deal with double GC problems, etc. It would be great if anyone out there helped me to narrow some of the issues with details, it'd be so much easier to fix. Things like:
are really precious to me. So if any of you would like to collaborate, you're welcome - I'll help as I can. IMO, before merging anything to the XF codebase, we'll need to solve those things first anyway. What do you think? I'm open for any solutions.
Thanks all for the good discussion. At this time I'm closing this issue. For many of the reasons stated above we're not going to pursue merging FFImageLoading.
As I mentioned, and I'll reach out to @daniel-luberda directly on this, let's break down the image related improvements to specific things Xamarin.Forms could add that benefit everyone including FFImageLoading. Please open new proposals on those individually. The more focused and specific, the better.
I highly encourage anyone interested to contribute to FFImageLoading with @daniel-luberda! Support him and that amazing project.
Hi @davidortinau , perhaps you can open a "little things on images" that makes a massive difference in Xamarin Forms then at least we have a entry (focus) point to further this discussion with specifics and your criteria for inclusion.
My wish list for the most basic addition to XF Image control would be:
1) RetryCount - the most basic implementation , I'm not asking here for polly.
2) Prefetch Image - in code behind an extension to image control where I can download the image in advance and cache it for specified days.
2) Better memory usage on images - looking at glide for example, better image handling looks to me like low hanging fruit that can make a massive difference to the Xamarin Forms ecosystem where the basics on image handling are propelled to excellent.
IImageViewHandler
/ IImageSourceHandler
You can now easily use FFImageLoading with standard views like Xamarin.Forms.Image
. Just call this after Xamarin.Forms.Init
call:
CachedImageRenderer.InitImageViewHandler()
on AndroidCachedImageRenderer.InitImageSourceHandler()
on iOS / Mac and others... and that's all. Also SVG files do work when providing SvgImageSource
as a Source
Most helpful comment
Hi everyone. Disclosure - I'm an author
FFImageLoading is quite a complex library, I've spend a LOT of time on it implementing new features, improving performance and fixes. It's quite stable now, but there're a lot of things to improve. It's not easy if you do it only as a side project.
For example, currently I implemented a new way of handling SVG images which I use heavily in some of my projects (not using bitmaps anymore, large performance boost, uses a lot less memory while still using the same APIs) and because of that I didn't really have time to check on issues on project's site lastly. I always try to merge all PR's (BTW: many thanks to all of the collaborators!), but most of issues are like "could you tell me what's wrong" - and it's a really time consuming job to analyse and debug every case if you're alone with it :)
Internally, FFImageLoading does most of the things just the same as Glide library, with the difference that we do it on .NET side, so sometimes we have to deal with double GC problems, etc. It would be great if anyone out there helped me to narrow some of the issues with details, it'd be so much easier to fix. Things like:
are really precious to me. So if any of you would like to collaborate, you're welcome - I'll help as I can. IMO, before merging anything to the XF codebase, we'll need to solve those things first anyway. What do you think? I'm open for any solutions.