IE dropping frames on preload of lots of huge images

[psirens]

I've been making an offline version of a Reel app for a client and everything works fine in Chrome, Firefox (a little slow) but in IE10 I noticed that during "preloading" whilst the bar is going along the bottom it will get to about half way then unexpectedly ZOOM to completion.

The result is half of the images in the Reel will show up as "black cross" when rotated - I think this is the replacement for the old "red cross" image not found. If you right click the image there is the option to "Show picture" which magically makes the image appear.

I have a smaller presentation with less images which doesn't have this problem, so does anyone know if there is an image/memory limit on preloaded images in IE?
Any possible solution?

[pisi]

Browsers should not impose any image count limit and Reel itself has none.

What does the IE's Developer Tools say? (especially the network tab)

[psirens]

I don't see any correlation between the timings bit and which ones aren't displayed, the transferred bytes seem to match up to the image size. (This is running it locally on apache rather than offline).
I'm using 150 images, 100mb in total, have you used such a dataset?

[pisi]

Interesting. Please click "Go to detailed view" and do one snapshot of a loaded frame and of the failed one. Thanks.

And yes, I have seen even bigger both in size and in quantity.

[psirens]

If I go to "response body" I can actually see the image of the unloaded image in detailed network tab.

[pisi]

Great! Some fairly large numbers in there - the occasionally huge response time, large gaps and offsets. Am smelling a network issue here, but since it is local, it could only be the webserver. If you're for a little experiment, make a blank HTML page holding only the 150 <img> elements and see if that loads ok.

Btw. what are your Reel options?

[psirens]

I'd be inclined to think the same thing but as I said I can run it offline from "C:" and I get the same result.

$('#reel').reel({
    indicator:  5,
    brake:      100,
    throwable:  false,
    preloader:  5,
    frames:     15,
    frame:      1,
    rows:       10,
    row:        4,
    revolution: 800,
    loops:      true,
    cw:         true,
    path: './images/'+folder+'/',
    images: folderframes(15,10,"png")
});

They do all load in (eventually), though I would say the first time I tried it it's noticeable they didn't load in any particular order, and comparing it against the time your preloader normally finishes - it had indeed only completed loading about half, before going back and showing the others.

[psirens]

OK I did some debugging and around the first stage of "preloading" when the bar jumps up, in "preload: function(e){" the event type (e.type ln 1129 in 1.3) starts coming back as "error" instead of "load" and it's the same for every image after that. I don't see any messages as to why ..

[pisi]

For greater clarity, you can switch off the scattered loading order with preload: "linear".

You mentioned this is an offline version of an online app. Does it happen in the online version too?

Also, I often find the file format to make a difference. Fastest of which seems to be JPG (even with maxed quality), then GIF, 8-bit PNG with the 24-bit PNG being the poorest performer. Have you tried other format(s)?

Also also, can you try the development version too? It has tweaks in the loading mechanism, which may have some effect.

[pisi]

Well, it looks to timeout or something, maybe. Please make that snapshot of the response headers tab in the detailed network view of the image, which fails.

[psirens]

Yeah it looks exactly 5 seconds from start of preload then every one after is "error" (I turned on shy mode, preload linear didn't seem to change the order..).

OK response:

Response    HTTP/1.1 200 OK
Date    Mon, 07 Oct 2013 15:24:07 GMT
Server  Apache/2.2.22 (Win32) PHP/5.3.25
Last-Modified   Wed, 02 Oct 2013 08:38:45 GMT
ETag    "16000000018707-b2cff-4e7bdff4e4f40"
Accept-Ranges   bytes
Content-Length  732415
Keep-Alive  timeout=5, max=98
Connection  Keep-Alive
Content-Type    image/png

Error'd responses: ((( file size is correct )))

Response    HTTP/1.1 200 OK
Date    Mon, 07 Oct 2013 15:24:08 GMT
Server  Apache/2.2.22 (Win32) PHP/5.3.25
Last-Modified   Wed, 02 Oct 2013 08:36:44 GMT
ETag    "b000000018252-b335b-4e7bdf817ff00"
Accept-Ranges   bytes
Content-Length  734043
Keep-Alive  timeout=5, max=88
Connection  Keep-Alive
Content-Type    image/png

Response    HTTP/1.1 200 OK
Date    Mon, 07 Oct 2013 15:24:08 GMT
Server  Apache/2.2.22 (Win32) PHP/5.3.25
Last-Modified   Wed, 02 Oct 2013 08:38:09 GMT
ETag    "1600000001851a-b290e-4e7bdfd28fe40"
Accept-Ranges   bytes
Content-Length  731406
Keep-Alive  timeout=5, max=78
Connection  Keep-Alive
Content-Type    image/png

[pisi]

5 seconds - that's it! If you inspect the response, there is timeout=5 in Keep-Alive field. This is a timeout imposed by your local webserver and it effectively says "stop trying if it takes longer than 5 sec". You need to raise this limit in order to load this number of files.

http://en.wikipedia.org/wiki/HTTP_persistent_connection says:

In HTTP 1.1, all connections are considered persistent unless declared otherwise.[1] The HTTP persistent connections do not use separate keepalive messages, they just allow multiple requests to use a single connection. However, the default connection timeout of Apache 2.0 httpd[2] is as little as 15 seconds[3] and for Apache 2.2 only 5 seconds.[4] The advantage of a short timeout is the ability to deliver multiple components of a web page quickly while not consuming resources to run multiple server processes or threads for too long.[5]

[psirens]

Sorry I did manage to change that to "Keep-Alive timeout=60, max=87" but it still happens on 127, and C:\ shouldn't have any server restrictions. I think it must be something in IE hitting a connection limit - it would need to rerequest errored responses .. or send requests in smaller batches?
I'm going to try it with JPGs or reduce the size of the images, then it should load under 5 seconds anyway, or just tell them to use Chrome! - plus the majority of presentations are far less complicated, thanks.

[pisi]

The thing is that they re not loaded in a batch or batches. They are loaded (started) asynchronously one by one 2 milliseconds apart to avoid race conditions.

Reel does not rerequest intentionally during preload, as that may as well end in numerous rerequest loops. Instead it rerequests the image naturally when it is actually used. I will investigate this issue more to surface some potential IE quirks with the error event. It shouldn't have to rerequest anyway. Server shouldn't cause an error on the client, especially when the response eventually arrives with status 200.

Please paste in response headers of the failed frame when serving it from C:\

[psirens]

Yeah, I'm not sure if it would help if it requested 10 at a time, then waited for the responses before doing 10 more, it's hard to know when the actual error is undefined, is there nothing more returned than event.type ?

The responses from C:\ don't really get tracked by IE, everything just comes back as < 1 ms, except for the Timings tab, here are two "black cross" responses and one ok:

I ran it 3 times there and console.logged the e.type==error, there were 67,67,68 errors, which is what it didn't get loaded to the page within 5 seconds of pressing the image on shy mode.

[pisi]

Please paste the response headers. Timings don't tell us much in this case. Thanks