gZip Question

[reddozen]

How would I set up my babylon files / packages?

Would the babylon file itself by gzipped, and would each texture be gzipped separately?

How will this effect the *.babylon file knowing that the textures etc are gzipped?

Lastly, what if you're only loading specific models from a package and not the whole package?

[RaananW]

I wonder what you mean with gzipping resources. (DK, correct me if I'm wrong but) babylon itself doesn't naively support unzipping downloaded resources.
Zipping textures is also usually rather redundant, as they are optimized at most cases.
If you refer to server side zipping, this is done by the browser itself. you have no control over it, other than turning it on our off.
When taking about a package, I assume you mean a babylon file. You will have to download the entire thing in order to load a single mesh. This is where a delay loading file comes to the rescue :-)

[jerome]

+1

 

Your browser (they all do this for years, now) will send a http content-encoding header asking the server for http compression support :

Accept-Encoding: gzip, deflate

The web server will then respond, if configured so to compress resources, with the http header :

Content-Encoding: gzip

Just check in your browser development tools (network tab) if these http headers are rightly exchanged between your browser and your server.

[davrous]

You're right, you don't have gZip support in babylon.js, we're simply based on what the browser & web server offer. All modern browsers support native gzip uncompress feature. You then just need to use a web server gzipping on the fly your content (IIS or Apache).

 

On www.BabylonJS.com we have put our content on a static CDN server, so we have gzipped ourselves the content and add the http header Content-Encoding: gzip.

 

I've shared how you've setup our hosting in this article: http://blogs.msdn.com/b/davrous/archive/2014/05/22/why-and-how-we-migrated-babylonjs-com-to-microsoft-azure.aspx

[reddozen]

Ok, I think I finally found a webpage that explains everything. All I was finding was how to set up the htaccess files and nothing about how zipping the files actually worked or interacted with the page.

[Dad72]

@Roddozen: Your link could be of interest to another person. can you give here please.

[gryff]

agree dad72. 

 

cheers, gryff

[reddozen]

Essentially, just keep a *.gz and uncompressed version of each file, and the site should send the compressed version where the browser allows for it, and if you're headder / ataccess file etc is set up to send them when available.

 

http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/

[gryff]

TY red

 

cheers, gryff

[davrous]

There is no need for uncompressed version. If your browser supports WebGL, it will support gzip.

David

[reddozen]

There is no need for uncompressed version. If your browser supports WebGL, it will support gzip.

David

 

 True...

[RaananW]

This is actually what's really fun about developing  WebGL related games/sites/whatever - no need to consider backwards-compatibility! If the browser supports WebGL it supports most if not all of what you wanna use :-)

[gwenael]

Hi guys,

 

@davrous, thanks for your link.

 

@davrous or others:

- Do application/babylon and application/babylonmeshdata are deposed as mime types? (http://www.iana.org/assignments/media-types/media-types.xhtml)

- If I use application/json instead (to declare .babylon files and .babylonmeshdata), will IIS gzip the files without I have to do so? Like I think it does for css, javascript...

 

Thanks

[jerome]

Hi Gwenael

 

I don't think application/babylonmeshdata will ever be deposed as a standard mime type among IANA... because it costs a lot of money to do this

Actually, it would be more certified to name it x.babylon-etc (http://en.wikipedia.org/wiki/Internet_media_type).

 

Major webservers implement only IANA standardized mime types.

This is the reason why you sometimes may have to declare your own babylon mime-type server side if the server is not configured to serve your babylon file with no (or blank) content-type header.

As the real format of these babylon files is internally json, you obviously can rename them by suffixing with .json (or associate them with application/json mime-type in the server settings).

 

That's said, what is gzipped and what is not in the http transaction ?

 

It is another webserver configuraton actually : the deflate module (may have different name depending on the webserver : IIS, Apache, Nginx, etc)

Usely, everything compressible is gzipped by default : html pages, css, javascript and json.

JPEG images aren't gzipped by the server as JPEG is already a compressed format : compressing something already compressed may result in something ... bigger.

 

Unless you have access to your webserver you should consider your json files are always compressed (you can call your sysadmin to be sure ).

This can be checked with the network tab of your browser dev tools : inspect http headers in the request response when loading your json file, you should see

Content-Encoding: gzip

This tells you the response had been gzipped

 

If you need more compression, then you have to deal with ... json itself.

Send less data.

Or minimize data.

Or both.

ex : json is a utf-8 text format, so instead of sendind full float values {x: 125.12562354546876542355}, you could eventually short them to a lower precision {x: 125.13} if acceptable for your application

 

Remember also utf-8 uses one byte per character if you limit yourself to old good ascii codes (127 first unicode chars). If you use other characters (french accents, greek alphabet, cyrillic, japanese katagana, chinese kanji, etc, etc) it will be 2, 3 or 4 bytes per character.