no, it wont. The idea is to configure web-server that it gzips pvrtc before sending
also switch on static gzip if its under heavy load
gzip is the part of protocol, not the file itself
its managed by web-server and browser
server sends gzipped file instead of normal one, and browser unzips it , and gives normal file to JS side
gzip by default is enabled for html/css, but not for other file extensions. You have to manually enable it in config, and if your server is under heavy load, configure and enable "static gzip"
Gotcha, thanks for the explanation. I thought only standard stuff could be compressed that way
well, its the best way unless somehow browsers start support for formats like BASIS/CRUNCH. Making JS-side uncompressor is not effective :( At least for our game emscripten-ed crunch was too slow.
In this particular case, I’m trying to find the right spot between transmission time and vram size
vram size doesnt depend on gzip
I know, but atm we’re using PNGs
but yeah, PNG can be switched to DDS/PVR with gzip
its not good for transmission time without gzip
Exactly, that’s what I’m trying to do
The deployment guys are going to hate me though haha
one really good thing is that I've added support for non-premultiplied textures in pixi
otherwise there would be big problem with alpha and blendmodes over compressed textures
yeah, I've seen the docs
you've done a great job man