New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IE dropping frames on preload of lots of huge images #237

Closed
lamiejang opened this Issue Oct 7, 2013 · 26 comments

Comments

Projects
None yet
3 participants
@lamiejang

lamiejang commented Oct 7, 2013

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?
rc_reel

@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 7, 2013

Owner

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)

Owner

pisi commented Oct 7, 2013

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)

@lamiejang

This comment has been minimized.

Show comment
Hide comment
@lamiejang

lamiejang Oct 7, 2013

reel_network

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?

lamiejang commented Oct 7, 2013

reel_network

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

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 7, 2013

Owner

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.

Owner

pisi commented Oct 7, 2013

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.

@lamiejang

This comment has been minimized.

Show comment
Hide comment
@lamiejang

lamiejang Oct 7, 2013

reel_loaded
reel_unloaded
reel_loaded2
reel_unloaded2

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

lamiejang commented Oct 7, 2013

reel_loaded
reel_unloaded
reel_loaded2
reel_unloaded2

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

@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 7, 2013

Owner

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?

Owner

pisi commented Oct 7, 2013

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?

@lamiejang

This comment has been minimized.

Show comment
Hide comment
@lamiejang

lamiejang Oct 7, 2013

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.
rc_loadtest

lamiejang commented Oct 7, 2013

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.
rc_loadtest

@lamiejang

This comment has been minimized.

Show comment
Hide comment
@lamiejang

lamiejang Oct 7, 2013

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 ..

lamiejang commented Oct 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 7, 2013

Owner

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.

Owner

pisi commented Oct 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 7, 2013

Owner

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.

Owner

pisi commented Oct 7, 2013

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.

@lamiejang

This comment has been minimized.

Show comment
Hide comment
@lamiejang

lamiejang Oct 7, 2013

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

lamiejang commented Oct 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 7, 2013

Owner

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]

Owner

pisi commented Oct 7, 2013

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]

@lamiejang

This comment has been minimized.

Show comment
Hide comment
@lamiejang

lamiejang Oct 7, 2013

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.

lamiejang commented Oct 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 7, 2013

Owner

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:\

Owner

pisi commented Oct 7, 2013

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:\

@lamiejang

This comment has been minimized.

Show comment
Hide comment
@lamiejang

lamiejang Oct 7, 2013

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:

reel_bc_localimage

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.

lamiejang commented Oct 7, 2013

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:

reel_bc_localimage

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

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 7, 2013

Owner

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

Owner

pisi commented Oct 7, 2013

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

@lamiejang

This comment has been minimized.

Show comment
Hide comment
@lamiejang

lamiejang Oct 7, 2013

Yes the other tabs are blank for local files.

Here's some rough timings from the C:\ version but I couldn't draw any conclusions from it, the number of files it loads changes every run. http://pastebin.com/YAwfxZP8
I can't give you my dataset but I could give you the code if you wanted.

The only similar case I've seen is this http://social.msdn.microsoft.com/Forums/ie/en-US/86a4ba1f-4b44-4c92-8d4c-71d903d963a7/ie10-aborts-image-downloads?forum=iewebdevelopment
http://stackoverflow.com/questions/15837502/ie10-aborts-image-downloads
I tried his example there with my data and got the same problem so it's not specific to your app. (84 dl - 66 errors, 150:0 in chrome/ffox).

lamiejang commented Oct 7, 2013

Yes the other tabs are blank for local files.

Here's some rough timings from the C:\ version but I couldn't draw any conclusions from it, the number of files it loads changes every run. http://pastebin.com/YAwfxZP8
I can't give you my dataset but I could give you the code if you wanted.

The only similar case I've seen is this http://social.msdn.microsoft.com/Forums/ie/en-US/86a4ba1f-4b44-4c92-8d4c-71d903d963a7/ie10-aborts-image-downloads?forum=iewebdevelopment
http://stackoverflow.com/questions/15837502/ie10-aborts-image-downloads
I tried his example there with my data and got the same problem so it's not specific to your app. (84 dl - 66 errors, 150:0 in chrome/ffox).

@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 7, 2013

Owner

There are number of things which can mess up things when loading. But the issue you linked leads me to think, that even if I rewrite the preloader to load in batches or even better respect some max concurrent request number, we still will be wrestling with the size. You too have pretty large images, right? If so, the compression/format may hep you to sort out as the lesser the format, the lower the memory requirements.

Can't you mail me just one frame of your dataset (in all confidentiality)?

Owner

pisi commented Oct 7, 2013

There are number of things which can mess up things when loading. But the issue you linked leads me to think, that even if I rewrite the preloader to load in batches or even better respect some max concurrent request number, we still will be wrestling with the size. You too have pretty large images, right? If so, the compression/format may hep you to sort out as the lesser the format, the lower the memory requirements.

Can't you mail me just one frame of your dataset (in all confidentiality)?

pisi added a commit that referenced this issue Oct 16, 2013

Redesigned preloader mechanism to be more sequential and respect maxi…
…mal number of open connections. This will hopefully improve IE's troubles with huge number of images. #237
@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 16, 2013

Owner

@lamiejang , I've toyed with the image you kindly mailed me and came up with a better preloading mechanism, which doesn't spit out all cache image sources at once (albeit in 2 ms interval) like the one before. This new one opens up 4 simultaneous "channels" instead, and (re)uses them for all preloaded images, so that only 4 concurrent requests are open at any time. This pretty much streamlined the loading graph, which now doesn't produce those gaps like before. I've successfully tested 250 of those frames of yours with no drop frames.

streamlined loading

Please test it too and let me know. It's in the development branch

Owner

pisi commented Oct 16, 2013

@lamiejang , I've toyed with the image you kindly mailed me and came up with a better preloading mechanism, which doesn't spit out all cache image sources at once (albeit in 2 ms interval) like the one before. This new one opens up 4 simultaneous "channels" instead, and (re)uses them for all preloaded images, so that only 4 concurrent requests are open at any time. This pretty much streamlined the loading graph, which now doesn't produce those gaps like before. I've successfully tested 250 of those frames of yours with no drop frames.

streamlined loading

Please test it too and let me know. It's in the development branch

@ghost ghost assigned pisi Oct 16, 2013

@lamiejang

This comment has been minimized.

Show comment
Hide comment
@lamiejang

lamiejang Oct 17, 2013

Thanks for the update, I have tried the latest but am still having the same issue in IE unfortunately.
Also, I don't know if you have tested in Firefox but it appears to have started doing something similar :r in the hires presentation I now get lots of

Image corrupt or truncated: ../images/rc_helicopter/photo_1_10.png
Image corrupt or truncated: ../images/rc_helicopter/photo_8_1.png
Image corrupt or truncated: ../images/rc_helicopter/photo_1_1.png"

I actually checked the memory usage of Firefox and in the new version starting from a base of 360mb it climbs towards 3GB immediately then starts dropping frames turning all white. I have the older dev version (2013-09-18) and it goes from 360mb to around 450mb initially, then as you spin the reel the images load in towards 3GB.

IE will start from 60mb and go to about 120mb then refuse to load any further without right-clicking "view image".

Chrome is ok as usual, 40mb window to 160mb loaded then 2GB as you rotate.

We don't really need the images this hi-res (2500x1875), they just didn't want to have to do any extra processing when adding new image sets in.

lamiejang commented Oct 17, 2013

Thanks for the update, I have tried the latest but am still having the same issue in IE unfortunately.
Also, I don't know if you have tested in Firefox but it appears to have started doing something similar :r in the hires presentation I now get lots of

Image corrupt or truncated: ../images/rc_helicopter/photo_1_10.png
Image corrupt or truncated: ../images/rc_helicopter/photo_8_1.png
Image corrupt or truncated: ../images/rc_helicopter/photo_1_1.png"

I actually checked the memory usage of Firefox and in the new version starting from a base of 360mb it climbs towards 3GB immediately then starts dropping frames turning all white. I have the older dev version (2013-09-18) and it goes from 360mb to around 450mb initially, then as you spin the reel the images load in towards 3GB.

IE will start from 60mb and go to about 120mb then refuse to load any further without right-clicking "view image".

Chrome is ok as usual, 40mb window to 160mb loaded then 2GB as you rotate.

We don't really need the images this hi-res (2500x1875), they just didn't want to have to do any extra processing when adding new image sets in.

@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 17, 2013

Owner

Hm, can't see the same thing in FF nor in IE. It loads fine for me in both of them (in all browsers I tested actually). "Image is corrupt or truncated" is most likely a transport problem or the browser interrupted the loading. Reel itself doesn't manage the network itself. Maybe it's because I serve the files by a local Apache webserver, not from file protocol (?).

The memory consumption is about right. You are loading 150 files with around 1,2 MB each. Which means roughly 180 MB download alone. Memory-wise these images have 4 687 500 pixels each and since in 24bit PNG one pixel takes up 3 bytes of memory, you're looking at 14,1 MB of RAM each such image occupies. With 150 images, you're facing massive 2,1 GB of data be kept in memory just for the images alone. I can imagine this fitting into memory, but can not easily imagine smooth playback of these as with the default tempo, you're up to some 500 MB/s throughput in the browser's rendering pipelines. This is rather huge number too as for example 720p video data rate is about half of that around 250 MB/s. You'd really need smaller images, dude..

Owner

pisi commented Oct 17, 2013

Hm, can't see the same thing in FF nor in IE. It loads fine for me in both of them (in all browsers I tested actually). "Image is corrupt or truncated" is most likely a transport problem or the browser interrupted the loading. Reel itself doesn't manage the network itself. Maybe it's because I serve the files by a local Apache webserver, not from file protocol (?).

The memory consumption is about right. You are loading 150 files with around 1,2 MB each. Which means roughly 180 MB download alone. Memory-wise these images have 4 687 500 pixels each and since in 24bit PNG one pixel takes up 3 bytes of memory, you're looking at 14,1 MB of RAM each such image occupies. With 150 images, you're facing massive 2,1 GB of data be kept in memory just for the images alone. I can imagine this fitting into memory, but can not easily imagine smooth playback of these as with the default tempo, you're up to some 500 MB/s throughput in the browser's rendering pipelines. This is rather huge number too as for example 720p video data rate is about half of that around 250 MB/s. You'd really need smaller images, dude..

@MartinPluta

This comment has been minimized.

Show comment
Hide comment
@MartinPluta

MartinPluta Oct 17, 2013

Recently, I had similar issues with large images (5000x 4000 pixels approximately). Think the issues is most browsers having a maximum limit on pixels shown per image. At least some previous FireFox versions had such a limitation. You might search for these browser specific limitations and check if your images are within the allowed number of pixels.

Best regards

Martin

MartinPluta commented Oct 17, 2013

Recently, I had similar issues with large images (5000x 4000 pixels approximately). Think the issues is most browsers having a maximum limit on pixels shown per image. At least some previous FireFox versions had such a limitation. You might search for these browser specific limitations and check if your images are within the allowed number of pixels.

Best regards

Martin

@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 17, 2013

Owner

Jamie, can you please provide screenshots of the network tab with the latest development version? One capturing start of the list and one with end of it. Thanks.

Owner

pisi commented Oct 17, 2013

Jamie, can you please provide screenshots of the network tab with the latest development version? One capturing start of the list and one with end of it. Thanks.

@lamiejang

This comment has been minimized.

Show comment
Hide comment
@lamiejang

lamiejang Oct 17, 2013

As far as I can see it's more a memory or timing constraint than pixels. I'm agreeable to having smaller images as long as I can say that's the problem. Was it intended for Firefox to cache all the image references in memory on initialize, rather than load in as you rotate, in the new version?

Here are the IE screenshots, stops after it loads around 100mb worth.
goodie
badie

Then I tried it with reducing the number of ROWS from 15 to 8, and all loaded fine (~60mb).
I increased it to 10 rows, and looked at the network tab, it loaded about 75mb but seems everything over 5s Wait time came back as error. I can't easily find anything about that being a server setting other than what we tried before ..
badiesingle

again it does the same loading from file:/// but you can't see anything in the network tab.

lamiejang commented Oct 17, 2013

As far as I can see it's more a memory or timing constraint than pixels. I'm agreeable to having smaller images as long as I can say that's the problem. Was it intended for Firefox to cache all the image references in memory on initialize, rather than load in as you rotate, in the new version?

Here are the IE screenshots, stops after it loads around 100mb worth.
goodie
badie

Then I tried it with reducing the number of ROWS from 15 to 8, and all loaded fine (~60mb).
I increased it to 10 rows, and looked at the network tab, it loaded about 75mb but seems everything over 5s Wait time came back as error. I can't easily find anything about that being a server setting other than what we tried before ..
badiesingle

again it does the same loading from file:/// but you can't see anything in the network tab.

@lamiejang

This comment has been minimized.

Show comment
Hide comment
@lamiejang

lamiejang Oct 17, 2013

In retrospect it might have just been luck it was exactly 5s, I ran it a few more times and it can be anything from 4.4s+, irrespective if it's from clean cache 200 or 304 non-modified.
It would be nice if you could repeat it, I'm on IE 10.0.9200.16721, but I'm unsure anyone really requires images this big.

lamiejang commented Oct 17, 2013

In retrospect it might have just been luck it was exactly 5s, I ran it a few more times and it can be anything from 4.4s+, irrespective if it's from clean cache 200 or 304 non-modified.
It would be nice if you could repeat it, I'm on IE 10.0.9200.16721, but I'm unsure anyone really requires images this big.

@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Oct 17, 2013

Owner

The three yellow requests at the breaking point seem to be requests with no response (without the blue part). Reel itself has no control over the loading, only waits for possible outcomes be it success or error. If server refused to respond, it wouldn't be 200 OK. So, the only remaining entity empowered to refuse response is the browser. For whatever reason it is doing it. Try fiddling with different values for $.reel.concurrent_requests. Default is 4 and reportedly browsers have between 2 to 8 concurrent connections limit depending on the connection bandwidth and version of the browser in question.

As far as I can see it's more a memory or timing constraint than pixels. I'm agreeable to having smaller images as long as I can say that's the problem.

Pixels equal memory. For example on iOS there is fairly low pixel dimension limit on each image resource to fit into its little allocated corner of memory. Also when you use images, which are larger than the actual dimensions you set, you also get a considerable CPU overhead in re-processing these images during scaling.

Was it intended for Firefox to cache all the image references in memory on initialize, rather than load in as you rotate, in the new version?

Actually, nothing changed and will change in 1.3 regarding the events order. What Reel does is it waits for all images to be preloaded before it starts to playback the animations. However you can rotate the thing from the time preload started and the spread-out loading order should provide you with enough images for such an early rotation.


Also we can safely rule out rows to be the cause. I reproduced this without rows, just with 250 images in a single row.

Owner

pisi commented Oct 17, 2013

The three yellow requests at the breaking point seem to be requests with no response (without the blue part). Reel itself has no control over the loading, only waits for possible outcomes be it success or error. If server refused to respond, it wouldn't be 200 OK. So, the only remaining entity empowered to refuse response is the browser. For whatever reason it is doing it. Try fiddling with different values for $.reel.concurrent_requests. Default is 4 and reportedly browsers have between 2 to 8 concurrent connections limit depending on the connection bandwidth and version of the browser in question.

As far as I can see it's more a memory or timing constraint than pixels. I'm agreeable to having smaller images as long as I can say that's the problem.

Pixels equal memory. For example on iOS there is fairly low pixel dimension limit on each image resource to fit into its little allocated corner of memory. Also when you use images, which are larger than the actual dimensions you set, you also get a considerable CPU overhead in re-processing these images during scaling.

Was it intended for Firefox to cache all the image references in memory on initialize, rather than load in as you rotate, in the new version?

Actually, nothing changed and will change in 1.3 regarding the events order. What Reel does is it waits for all images to be preloaded before it starts to playback the animations. However you can rotate the thing from the time preload started and the spread-out loading order should provide you with enough images for such an early rotation.


Also we can safely rule out rows to be the cause. I reproduced this without rows, just with 250 images in a single row.

@pisi pisi closed this Nov 4, 2013

@pisi

This comment has been minimized.

Show comment
Hide comment
@pisi

pisi Nov 5, 2013

Owner

Released today as part of v1.3.0

Owner

pisi commented Nov 5, 2013

Released today as part of v1.3.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment