Improve loading experience

[captbaritone]

Since we now require a javascript library, and we don't start requesting the skin asset until all the javascript has been downloaded, it can sometimes take quite a while before Winamp actually renders. I would like to see a few things happen to improve that experience.

1. Give the #winamp div some kind of content or default state that indicates that work is being done. Maybe the Windows hourglass cursor in the center? This state will be disabled once the skin is applied.
2. Try to pre-load the skin file and audio so that they are already cached when we get around to asking for them. This could probably significantly improve the loading speed.

[PAEz]

Application cache might be good here....
https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache
And then store the unzipped theme assets in local storage, saw a good library for that once but for the life of me cant find it now....still, wouldnt be toooo hard to implement.
Youve got 5meg in local storage (except REALLY old android browser that have 2meg), so should be enough for most stuff. Or you could go to indexdb (50meg on average I think...atleast 20), but then that doesnt work in old safari iOSX or whatever it was. That said your using some pretty new tech so why not just do the old "modern browsers only". iOS got it recently, but from what I read its rather buggy and buggered if Id support two different db's....really sux, Im dying for indexeddb to be universal AND for them to add a command to let me know how much memory its taking up...grrrr.

[captbaritone]

That would help with subsequent loads, but browser http caching should do that anyway. I'm thinking mostly of the initial load.

[PAEz]

The biggest thing (besides images) is the zip js. So if you went back to initiating the initial theme images from css and not a zip then you wouldnt need to wait for that to load before showing winamp (plus the unzipping is going to take a tiny bit o time). Then really the only big stuff is the images and if you turn those bmp to pngs (havent tried gif yet, which they could be as they all seem to be 256 colours) the theme ends up being 83k including the text files. And once you combine and minify the rest shouldnt be much.
Not that Im saying a loading state is bad (not at all, I only recently left dialup and still care about this stuff), but you could lessen its need.

[captbaritone]

The zip file, while large, actually improves the transfer (compared to th the raw bmps) since it's compressed. It's only about 100k and means we only need one connection. I think the main problem is that the download of the zip is blocked by the download of everything else, including the zip library.

Ideally the zip library and the skin zip (and even lama.mp3) should be able to be fetched in parallel.

I think there are some tricks where you basically request the file at the top of the html file. Then, later on, when we actually want it the browser has it in it's cache so it loads instantly.

Jordan Eldredge

Please excuse any typos or terseness; this email was sent from a mobile device.

On Nov 17, 2014, at 4:53 PM, PAEz notifications@github.com wrote:

The biggest thing (besides images) is the zip js. So if you went back to initiating the initial theme images from css and not a zip then you wouldnt need to wait for that to load before showing winamp. Then really the only big stuff is the images and if you turn those bmp to pngs (havent tried gif yet, which they could be as they all seem to be 256 colours) the theme ends up being 83k including the text files. And once you combine and minify the rest shouldnt be much.
Not that Im saying a loading state is bad (not at all, I only recently left dialup and still care about this stuff), but you could lessen its need.

—
Reply to this email directly or view it on GitHub.

[PAEz]

The zip file, while large, actually improves the transfer (compared to th the raw bmps) since it's compressed. It's only about 100k and means we only need one connection.

Just nick picking.....unless your on a real slow computer or something like a tablet/phone in which case the unzipping, converting to base64 to put in the css and then the decoding of the base64 to display could actually make it worse, maybe. This is going on some stuff that showed base64 in the css could actually be slower than if it had to do multiple requests. Want one download with no converting, you could create one big sprite sheet with all the original images.....be a pain tho.

I dont know jack about ths sorta stuff coz its never come up for me (most stuff I do is local or a chrome extension which is local), but would async help with this?
http://caniuse.com/#search=async

[Akamaozu]

I spent some time poking around the code to find out what exactly about it is making it horrendously slow and I ended up finding this in jszip's documentation:

An other limitation comes from the browser (and the machine running the browser). A compressed zip file of 10MB is "easily" opened by firefox / chrome / opera / IE10+ but will crash older IE. Also keep in mind that strings in javascript are encoded in UTF-16 : a 10MB ascii text file will take 20MB of memory.

If you're having performance issues, please consider the following :

Don't use IE <= 9. Everything is better with typed arrays.
Use typed arrays (Uint8Array, ArrayBuffer, etc) if possible :
If you generate a zip file, you should use type:"uint8array" (or blob, arraybuffer, nodebuffer).
If you load the file from an ajax call, ask your XHR an ArrayBuffer. Loading a string is asking for troubles.
Don't use compression (see below).
If you want to get the content of an ASCII file as a string, consider using asBinary() instead of asText(). The transformation "binary string" -> "unicode string" is a consuming process.

Source: http://stuk.github.io/jszip/documentation/limitations.html

Seems like using jszip is likely to create performance issues even on the most capable browsers. I'm going to side with @PAEz and recommend you use application cache. I'm using it in an app (http://wholesale.mizbeach.com) with a much higher memory footprint than yours, as well as a very big library (React.js) and I'm experiencing no problems whatsoever performance wise. For all intents and purposes, my app should be much slower than yours, but it's leaps and bounds faster simple because I package the app in appcache and you're using jszip.

[captbaritone]

@Akamaozu Thanks for looking into this for us. I'm not intimately familiar with the application cache, but my understanding was that it was for storing data. How exactly does it help with memory intensive operations? You write to the cache instead of a variable? I'd love to see an example, or pull request ;)

Also, are we sure that the unzipping is really causing a bottleneck? I would assume that waiting for the network data (especially when it is being fetched serially) is orders of magnitude slower than even very complicated/slow computation.

Here is a screenshot of the network profile from Chrome. On this airport wifi, it's taking about 2.25 seconds to fetch all the assets. Notice how llama.mp3 and base-2.91.wsz don't start downloading until after winamp.js has completed downloading. You can also see that the data:img/bmp... images (which are created by the contents of the zip/wsz) start being loaded milliseconds after the skin file finished downloading. I assume that means jszip has done it's job in that time.

My computer may be faster than others. Do we have any profiling data to really show that jszip is causing a significant bottleneck for some users?

[PAEz]

Notice how llama.mp3 and base-2.91.wsz don't start downloading until after winamp.js has completed downloading.

The reason I mentioned the application cache is for the above.
https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache
From what I read there the files are all downed in parallel and then when you request them after (including by xhr) then it will get it from the cache. So the downloading of those two assets should start before their requested.

The unzipping shouldnt be much of a pain for this file because its rather small....unless, as I stated before, your on a slow computer/device and then it really could be. Akamaozu's advice to use an uncompressed zip is right. When a zip is uncompressed it is piss easy to decompress and involves no maths as its just header crap and block locations. If you convert all the images to png and rezip with no compression its actually a smaller file (85k compared to 98k) and worked fine (no bitching in the console, in Chrome anywayz). Here's one for you to try....
https://www.dropbox.com/s/a5xdte9qszrxy1w/base-2.91.wsz?dl=0
...images where converted , renamed and optimized.

OH, and if your thinking of using the app cache then read this...
http://alistapart.com/article/application-cache-is-a-douchebag
...its a MUST read.

[captbaritone]

Didn't find any simple way to pre-cache the skin file, and we now have a loading state (0bb44e7), I'm closing this.