We Keep Coding

Changed background image in 2d JavaScript game, now getting "Image Decode" freezes

I've built a 2d JavaScript game using a single PNG image as my canvas background. It's 13500x7500px and 1.5MB in size. My game ran smoothly until I realized I needed an even bigger image, so I switched it out to a 17500x7500px and 2MB PNG file and am now getting freezing every animation loop.
My question is twofold - first, what is happening differently now than before? I didn't change anything other than the image. Is it some kind of caching issue?
And second, how can I stop the freezes from happening? I'm hoping I don't have to recode everything to incorporate an image splitter that pieces in smaller parts of the background as I move.
The thing is when I switch the original 13500x7500px image back into the program, it runs smoothly, even on different browsers. It's just with the bigger image I have an issue with.

Node-Webkit Application: Loading thousands of images from disk

I have created a node-webkit application that loads thousands of images (7,480 to be exact) from disk into an HTML table. After about 3500 images, the loading stops. In the console, I see ERR_INSUFFICIENT_RESOURCES. According to Task Manager, the memory (private working set) for my app is at around 1.37 GB when this happens. How can I prevent this from happening? Is there a way for me to increase this limit? What additional details should I provide to receive help?

In the past when i have faced a similar problem, i held the images in memory, and inserted them into the dom as they scrolled into view.
I created two queues one for images not the scroll down to, and one for images that have been scrolled past. this way only images that are visible are present in the page.
If the download time is an issue try loading them into memory and see what happens, there is a chance the limit you have encountered is about placing images in the dom, and not necessarily loading the images into memory, worth a try.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/Image
var myImage = new Image(100, 200);
myImage.src = 'picture.jpg';

Is there a way to avoid javascript audio hiccuping while your program is loading other media at the same time?

I'm building a WebGL program where the scene changes at certain intervals. The scene change consists of destroying the previous scene, and loading up a new one, which means loading some texture files along with it.
At the same time, I'm also playing some audio throughout the program, that should keep playing during the destroy scene/create scene process. The program works fine, but I notice that when I'm loading the new scene with the new assets, the audio hiccups right before all of the new assets are finished loading.
Is there anything I can possibly do to prevent the small hiccup during the new load? I don't think its a file size issue, or an audio buffer issue, since all of the assets including the audio are pretty small (500k or less).
Any ideas would be helpful!

The hiccup was caused by the heavy javascript processes during the switch and was interrupting the audio. I managed to fix this issue by using the Web Audio API instead of the javascript Audio() object, which allowed the audio to play in a different context than what the program was running in.

How do I cascade start multiple gifs?

I have a gif of a candle with an animated flame. My webpage will show a few of these gifs in a row. It would be much more realistic if all the gifs didn't start at once after the page loads (otherwise I get a line of 'synchronised' candles).
I can create multiple gifs with different flame animations and then randomise which ones get shown but this will take extra bandwidth and will add an extra level of complexity.
Is there a way to maybe cascade start the gifs? i.e. start each one after a random amount of time in order that they are out of synch and look a bit more realistic?
Maybe using jquery? Or simple javascript?
Many thanks

You can't do that.
If you place the same image on multiple places, it's going to always look the same.
You could edit the image and change the order of the frames within the gif, save and repeat this a few times, and then load the gifs, but this will only work if the images are already loaded (cached) on your browser.
If this is the first time you load the page, it could just happen that an image will be loaded exactly when another image started from the first frame of the loaded image, so it will look as if they are in sync.
You could load the images using setTimeout but this will have the same problem as described above when the user first enters your page. You can delay the request for loading the file, but you have no control of the speed in which the file will be downloaded and therefor no control on when exactly the first frame will start playing.
If I were you, I'd try creating a big sprite of different images, each starting the animation from a different frame. There will be only one request and all animations will play together, making sure frames are never in sync.
When displaying the images on the site, make sure to properly show only the part you want for each image. This will give you the effect of flames burning at random times.

Google Chrome Image Ceiling?

We’re using Chrome for an interactive installation and appear to have hit some sort of image loading ceiling.
The app is built for a multitouch device and runs at 1920x1080. It's built on backbone and involves the rendering and removing of a large number of views which contain sprite animations (facilitated by the stepping of transparent png background images).
We’re preloading all of the images and listening for completion using David Desandro’s imagesloaded plugin. This worked perfectly at first (with less assets) and appears to work now, until you navigate further into the application. Despite the absence of 404s in the console and the confirmed presence of the files some of the images aren’t loaded and simply don’t appear. The problem persists even if we don’t preload the images.
The typical size of an animation sequence is 92250px x 450px and they come in any where between 1mb and 10mb each (that's after they've been optimised using the compressors behind grunt-contrib-imagemin). The image assets total is around 300mb.
What we’ve tried:
Applying any cache related flags in the chrome command line arguments when launching chrome (http://peter.sh/experiments/chromium-command-line-switches/) such as --disk-cache-size.
Caching all of the media assets using the HTML5 cache manifest.
Testing on different machines, both mac and PC. This produces the same results.
What we’re currently trying:
Reducing the size of all of the images by removing every other frame in the animations. This isn't ideal.
Changing the animation method to switch out (preloaded) individual images rather than sprites.
Preloading images in batches just before they're about to be added (not ideal).
Ideally we'd like to remove the ceiling on whatever this limit we've hit is. Any help/insights would be appreciated!

Whilst we haven't really got to the bottom of what is causing this issue, we have implemented a work around. Switching out the large sprite sheet animations for individual PNG frames does the job. I'd still be interested to learn exactly what the issue/limitation was for future reference...