Add support for WebP
Solido opened this issue · comments
Hi flutter team,
During my testing phase I discovered that using NetworkImage
- WebP is not supported currently
- Animated gif will only display the first frame (already great)
Can it be in public documentation and maybe have a follow up ?
In a UI having animated gif and control on the loop is really a great feature,
look at facebook reaction buttons as an example.
WebP because I was expecting to convert all my users upload to this format
but the lack of this feature currently will move the priority. Others may be happy
to read it in the doc.
Regards,
Supporting animated GIFs is #204
Adding WebP is just a binary-size trade-off. We should measure how much binary size it costs to evaluate the trade-off.
Thanks for considering this feature. Since Flutter is mobile first currently and comparing the size of an animated Gif to an animated webp : http://www.androidpolice.com/2017/05/01/animated-png-format-compare-animated-webp-gif
Size benefits are really huge for animated webp but maybe not that much with still images.
Consideration of the benefits should also include the gain of internet bandwith in highly graphical context not only for application first load size. In my case if Flutter support webp it can also drive my server cost to go much lower.
Thanks for the feedback! We're curious how much our engine size will grow if we add support for WebP. But I personally agree, WebP is a useful format for when load times and bandwidth costs are important.
Since the last few versions of Android Studio, there is an option to convert all your assets to WebP which I'm sure many do to save up room in their apk (as I have).
WebP while not a blocker could be a barrier for someone porting their app over since they have to get all their assets back to png/jpg
In my case app users are generating all the content and I'd like to encode it as webP/webM as the results is 30/40 % gains in the size/cost. Same problem than Google+.
I may not represent the majority of use cases and I understand that engine size is top priority for speed.
It can be totally acceptable for me to have it as an engine plugin in the rendering core that I have to declare somewhere if the architecture permit this.
Thanks you for handling this case ;)
We intend to support video through our plugin system: #2319, once that's done, presumably it should also be possible to wire up video-like things, possibly even additional image decoders like webp through a similar means. But that will mean the plugin may (or may not) contain a webp decoder, which means your app would contains such, and may negate some of the binary size gains you hope to achieve through webp, not sure.
Thanks Eric, I just want to make clear that the gain is on the server side. If I got several thousands of users uploading medias by encoding to webP/M I'll gain ~30% size/costs compared to storing using jpg, png, etc on many gigs.
It's more than acceptable to paid let's say 5mo in app size and have the codec saves me bandwidth and storage (A LOT). I got those medias by new Image.network not by bundling assets.
I want to also point out that the Android docs recommend using WebP to reduce the size of your APK: https://developer.android.com/topic/performance/reduce-apk-size.html
To gather data about how much this will increase the size of the engine, we need to:
- Flip this flag: https://github.com/flutter/engine/blob/master/tools/gn#L66
- Drop https://chromium.googlesource.com/webm/libwebp into //third_party/webp
- See how much the minimal app size benchmark regresses.
The currently wired up decoders are JPEG, PNG, GIF, ICO, BMP and WBMP.
I would trade BMP for WebP any day, if we're worried about engine size :)
What's missing from this bug is someone doing the investigation described in #9857 (comment). With that data we can make a call as to if we can just turn on webp in the default engine or if we need to look for more exotic solutions.
I used a gzipped libflutter.so with and without libwebp as a rough estimate.
The difference is about 161k for adding webp (3357766 without webp, and 3522928 with it)
Talked to @chinmaygarde and we think it's reasonable to add.
I'll followup with adding it to the engine and track how it affects the size benchmarks.
If you think adding 161k for webp is too much please comment.
161k sounds like a very worthwhile tradeoff. As @sethladd notes, we probably could remove some of our other codecs later (unclear how much they'd save) when we look more holistically at binary size.
Is it worth estimate what we'd save by removing BMP and ICO? (presumably, those could be implemented in Dart code if someone really needed them?)
Thanks @amirh !
Thanks!
Note that this will only be available in master after an engine roll (should happen in the next few hours)
Engine rolled with WebP support.
The basic material app size benchmark went up by 159k for Android, 184k for iOS.
How to compare progressive jpeg with webp? Instagram is doing progressive jpeg. In respect of data and processing comparisons.
Webp on Android, added as asset works without any problems. Please clarify, will it work on iOS or not? Official documentation does not say anything about it, it only says webp assets are supported in Flutter. Will iOS be able to display webp asset or not?
It seems webp assets work just fine on iOS.
Hi, which version of flutter did support the webp format for ios?
thanks.
I wanted to save webp image to gallery on flutter.
but failed.
any solution on it?
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.