Some engine size numbers (since I know @AGulev wants to know 
)
Release builds, stripped
1.2.179 2635564
1.2.180 2553284
-80kb (~3%)
1.2.179 2024820
1.2.180 2092295
+64kb (~3%)
1.2.179 2160378
1.2.180 2187290
+~26 kb (~1%)
32 kb was added for the WebGL 1 fallback
In all honesty, I would have thought that the engine would have decreased even more since WebP was quite big. But I guess they were more or less the same size then. 
Piggybacking on this topic, but as I’m trying to compress my resources for iOS and Android. How do you know which FORMAT to chose?
Luminance, Luminance alpha etc don’t sound familiar, I don’t know which one to chose from. I use regular pngs and spines, which one would you pick and why? Thanks
(If this is off topic I will delete my post)
Check out this thread
awww, thx!
Then it’s time to exclude the video recorder by default! =) For me it was a surprise that webp and the recorder uses separate codecs lib. I was sure the recorder use the format it uses just to avoid using separate vpx lib.
Yes. But also note that the video recorder is excluded by default on release builds, so you won’t save anything there
2 html5 build reports.
one in 1.2.179
the other one is in 1.2.180
All the settings are the same.
web.zip (340.9 KB)
It seems like for html5 build the new compression is worse than webp
When you say worse, I know you mean size on disc.
But what about the texture quality? And the fact that we support hardware textures is also a plus.
And, as I’ve mentioned before, the devs are working on more optimizations for the compression size.
True. You right. I take into account only one aspect.
7.29 vs 5.83 mb it’s a big difference for web. what about the idea to keep current webp lossy from 1.2.179 to 1.2.180 but with other title? 
I don’t see it as very likely that we’ll add WebP back as a builtin compression format. Supporting many separate technologies is an added extra development cost.
We will however be supporting custom resource formats later this year (and we’ll keep this feature in mind when we do). In that scenario you should be able to compress the data any way you want.
Another feature I would like to see as a saving for games chasing the last megabytes, is an api to supply a font with font glyphs. That would enable a game to avoid bundling with a lot of font data.
I want to raise this topic again, my html5 build report of (Raft Wars Multiplayer game)
this is a very big difference for html5 games + ~2.45 mb,
and we see 3.76 mb vs 6.07 mb of atlases size ( > 60% bigger)
we’ve tried for a very long time to reduce the final build size by every 1 megabyte, if check again the video posted by @aglitchman the video Size matters: how loading is losing you players in his topic, such a difference may affect income. 
I agree, it’s not ideal, and we’ll look into it.
Either the basis library update will improve the situation, or we’ll have to come up with a way to use webp again (e.g with an appmanifest).
UASTC is for extremely high quality (similar to BC7 quality) textures, and ETC1S is for very small files. The ETC1S system includes built-in data compression, while the UASTC system includes an optional Rate Distortion Optimization (RDO) post-process stage that conditions the encoded UASTC texture data in the .basis file so it can be more effectively LZ compressed by the end user.
Does it have features for compression amount?
Maybe reaching out to Binomial and showing them the Defold use cases would encourage them to improve compression amounts / have some advice.
@BunBunBun what is the Compression option you have set in your texture profiles when doing that test? Best?
Are you using Live Update already for minimizing initial load? Maybe worthwhile to do that in either case if you are not already.
They had very little. That’s what we’ve been waiting for.
Hopefully their new release adds the RDO optimization, which should have a parameter to tie more closely to our compression level.
Our current compression yields 8 bits per texel. With RDO, we should be able to get down to 4 bits with the optimization parameter.
Of course we can use the Live Update feature 
(and it is planned) but this topic about the texture compression.
Bundle size is very important for HTML5, 1MB makes a lot of difference. I think HTML5 is one of Defold’s strong suits over other engines, so reports of increased HTML5 bundle size are discouraging.
I also vote for still supporting WebP, at least until the new format supports better compression, so there is some transition period.
Thank you all for the feedback! We definitely take your opinions very seriously and I can assure you that we will look closer at this. For one, we will update to the recently released version of Basis. It will reduce size and increase speed. We will also look into reintroducing WebP but as an opt-in solution.
We will look into these changes soon, the Basis upgrade most likely for 1.2.181. Development of 1.2.182 will start on Monday and I believe we may be able to look at WebP then.
For now our recommendation is to stay at 1.2.179 if the increase in texture size isn’t acceptable.
