Well you made my bucketlist
you might see it back on edgehero in the future
Very cool, Arnold! Thanks for sharing.
Very well done, Arnold
Very impressive A huge work to fine tune every sub-animation in the main timeline.
But I must mention that with a connexion like mine (2,6 Mbps, yes, I know, it's not representative) the preloading phase is very long and the execution jerky.
I was wondering what could optimize the loading :
1) use EdgeCommons to load sub-animations at different points in the whole sequence ?
2) load graphics (I imagine that they are PNG32 files in the images folder) on demand ? Trying to understand what's happening under the hood (may be, Elaine, you can enlighten us) : every graphics instantiated somewhere in this long timeline has to be downloaded in one go during preloading ?
I'm pretty curious what device and browser you were using, and at which points the animation was most jerky. Part of this for us is exploring the actual limits we're hitting in practice.
For example, when you're using Chrome, which itself performs well, we'll upscale a few of the most important assets to 4x their original resolution. Unfortunately, this seems to be enough to push it over the limits of some integrated graphics cards. On mobile devices, we use low bitrate mono audio instead of a higher bitrate stereo sound, because the webaudio decoding of the full stereo sound causes a lot of stuttering during the initial animation.
But this landscape layer ( http://www.debuckettrip.nl/design/edge/parallax.oam/berg-anchorlayer3-1080.png if you get the high res version art 7200x850) is already 24MB, fully decompressed. Any assets we would delay the loading for would only be a fraction of that (the only other asset that I guess we could've saved quite a bit on, would be the northern light layer at the end. It was hard to compress it, as far as I understood, the northern light effect there is not rendered, but based on an actual recording of the nothern light. so no chance of decomposing it into something 'simpler')
We've experimented with cutting the landscape into separate pieces, so we could try hiding the invisible parts until we need them, but that caused a lot of 'tearing' of the landscape during the horizontal panning - we found it impossible to keep them seamlessly connected. So we've had to keep it as one big layer.
Thank you for reporting your experiences with so much details. We can see that your solution has been carefully evaluated.
Indeed, the landscape layer is too much for the 2,6 Mbps connexion I have here in the (little) mountains, far from the high bandwidth connexions which are current in town
PS : I am running Firefox 25 on a Mac mini 1.83 GHz Intel Core 2 Duo.
For the landscape, all you have to do then is to look outside in winter? :-)
Thanks for the data. We've found Firefox' performance to wildly differ between platforms: Windows seems to do a lot better than Mac, and you really don't want to try it on Linux. It's probably a quality of gpu-driver-integration issue.
Chrome performance is much more consistent between platforms.
I checked it on my iPad and it was great - loading was pretty fast and all worked nicely. Great impressive work!