ERR_INSUFFICIENT_RESOURCES..."a lot of image files"...
Okay, I ran the test.
There's a TON of images that are being loaded, and they're probably going to stay loaded even when not in use.
And since there's so many images, it's using up a ton of memory.
Just a guess, though.
Unfortunately, this is a problem with Construct 2 loading too much.
Which can't be fixed without telling the Construct 2 developers to stop loading images in advance, and to unload images if they haven't been in use for a while.
So basically, there's nothing that can be done short of patching the output from Construct 2.
But the way it's laid out, you'd need to make a patcher program to do it, because every time the game is rebuilt it will need to be repatched, and as resources are added the line numbers will change.
Also, remember that the patch has to remove resources that aren't in use, or everything will just fail once enough stuff has loaded(as in, when someone is at a certain point through the game)

Browsers lazy-load images. Construct 2 simply points the src attribute of Image objects to their paths, and does not use them. Browsers then lazy-load them the first time they are used. So it should not actually be loading much on startup. If it works in Chrome but not in NW.js, then it suggests perhaps NW.js has broken this lazy loading scheme or otherwise broken the ability to load multiple images.

BTW this demo uses ~450 images which isn't actually a whole lot considering it's already spritesheeting an even greater number of images. We've seen real games using thousands of images.

Finding this to be a problem as well. ( not using construct2).
Isen't there a chrome-arg for increasing or disabling this limit for an offline app?

Yes, please address this issue, thanks.

Would be great if you guys could take some of your time and look into this matter.
Having the same issue as well.

Will look to fix this. Could anyone please provide the case?

Thanks Roger!

What do you mean by 'provide the case' though? Anything you need from me here?

@JustASquid a sample application to reproduce the issue.

@rogerwang is the attached zip file with exported nw project for osx insufficient?

You should be packaging your images into fewer larger images, and then using chunks of those images. Probably running out of graphic handles.

You need to use a sprite sheet.

http://firefoxosgaming.blogspot.com/2014/10/tile-maps-in-construct-2.html

This will improve memory pressure, resource handle usage, and load times.

@DanielJoyce

I do use sprite sheets! even so, there are a lot of them because C2 spritesheets on a per-animation basis.

Anyway that point is moot since it works perfectly fine in Chrome as well as older NW versions.

@rogerwang has there been any progress on this? It's a pretty big deal for me.

@JustASquid As a workaround have you tried not packaging the images in your NW.js project and just have them called from a folder in the same directory as your NW.js binary?

@baconface images are not packaged for mac export anyway, they are stored unpackaged in a subdirectory. not sure about linux, but they have the same problem so that probably won't fix it, unless I'm misunderstanding you.

Could you try to pass --file-descriptor-limit=8192 via command line ?

does --file-descriptor-limit=8192 fix the issue?

@RIAEvangelist @ghostoy I'm already using --file-descriptor-limit<10000> - is there some significance to the number 8192? also I noticed the syntax is slightly different.

if you run ulimit -a in terminal you can see your current file-description limit.
default on mac seams to be 256?
going to test increasing the limit.
This would be neat if we could call this from package.json run arguments

@JustASquid not sure, but there was a week since it was suggested as a solution, and was wondering the outcome. Perhaps the formatting may make a difference.

@morgondag looking forward to seeing your results.

@JustASquid Please run ulimit -a -H to show your hard limit on file descriptor. If there is a hard limit, you can't exceed it normally. Then you have to set your hard limit and restart your laptop.
The syntax you are using is wrong and please try --file-descriptor-limit=10000.

@ghostoy @morgondag @RIAEvangelist Thanks for your help!

I've managed to change ulimit -n by the command line. (Not called file descriptor limit, but called 'open files'.) It was indeed 256 by default.

Doing this manually made the test app run fine. I changed the argument in package.json from '--file-descriptor-limit<10000>' to '--file-descriptor-limit=10000' but it didn't seem to work.

Anyway, I don't want to have to ask my users to manually play around with system config like this. Is there any way to have the app change the file limit?

also, more screwing around has meant that the hard limit has been set to 256 - anyone know how to fix that? I tried sudo launchctl limit maxfiles 4096 8192 but that had no effect.

My mac is running OSX Yosemite v 10.10.3.

@RIAEvangelist So it actually seams to fix my launch issues.
Keep in mind I have my .app on steam so adding the launch argument
--file-descriptor-limit=10000
Ad then running the application thought steam now starts as expected.
How ever there might be some cache going on.

ulimit -a

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 709
virtual memory          (kbytes, -v) unlimited

ulimit -a -H

core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) unlimited
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 65532
cpu time (seconds, -t) unlimited
max user processes (-u) 1064
virtual memory (kbytes, -v) unlimited

I have a rather old macbook air I'm testing on.
If anyone want to give it a try send me an email and i can hit you up
with a cdkey for steam:
kim@morgondag.nu

@JustASquid you could try something like node-cmd?

npm install node-cmd

var cmd=require('node-cmd');

cmd.run('ulimit blah blah');

if it's cross platform you will have to handle the various OS commands. Should be simple though.

@morgondag sweet write up! would help if I had a mac.

@ghostoy @morgondag @RIAEvangelist

My post seemed to post weirdly out of order, just replying again because there are still some unanswered questions. Mainly, what's a good way to do this without screwing with the user's computer, or requiring the user to screw with their computer? For linux people it wouldn't be a huge hassle but mac users aren't always going to be tech savvy.

@JustASquid --file-descriptor-limit has to be passed as command line argument. It DOSN'T work for chromium-args in package.json. That means you need to start nw with nw --file-descriptor-limit=10000 path/to/your/app.
limit -n reports the soft limit and it can be fixed by passing --file-descriptor-limit correctly. But for hard limit shown by limit -n -H, you can't work it out except reset it by root user. Fortunately in your case, it's "unlimited" as usually do.

@JustASquid Please refer to this link for setting hard limit on Linux and Mac.

@ghostoy OK, thanks!

I managed to get it working consistently by opening the app with the command line and using --file-descriptor-limit=10000.

I'm using construct 2 which exports the application as a .app file.
What's a good way to have the app set this launch option automatically? I looked it up but the most common solution involved running Automator to wrap the app in another app or some weird stuff like that. Is there a simple way? Even better, is there a way to do it that would let me apply the change on my Windows machine? Currently my workflow to publish the game doesn't require using a mac at all and I'd like to avoid that if possible.

Thanks so much for your help!
Daniel

EDIT: Actually, apparently it's still occasionally hanging on load even when passing that argument. looking into it more now...

Yeah, it's still hanging on load sometimes, giving the same errors.

this is with ulimit -n definitely being 8192 and also passing --file-descriptor-limit by the command line as a launch option.

Soo... it looks like the issue might be elsewhere?

Do you REALLY need 8000 open file descriptors? Are you remembering to close
them after loading assets? I suspect you are leaking file descriptors.

On Sun, Jun 14, 2015, 00:20 JustASquid notifications@github.com wrote:

Yeah, it's still hanging on load sometimes, giving the same errors.

this is with ulimit definitely being 8192 and also passing
--file-descriptor-limit by the command line as a launch option.

Soo... it looks like the issue might be elsewhere?

—
Reply to this email directly or view it on GitHub
#3307 (comment).

Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

@DanielJoyce

No, I don't need 8000 but I need more than 256. I'd guess I have about 500 or so images. I have no idea how it works under the hood but i guess it's trying to 'open' all those files at once?

I still haven't seen anyone explain why it works in Chrome but not nw.

going to run some more test on my .app i have seams like some of you still get hangups?
So the case with all the files on these types of applications is that they usually load sprites of images beforehand so they are always available in the application. ( often canvas/webgl). See any JS bases game-engine (phaser/impact/Contruct).

So changing the applications and engines is not a solution to the problem.
it works in chrome but not in NW.

is there a different file limit set for nw? Why?

One thing I have done for some image software I built is to load the images as base64.

It has fixed the issues I was having and I am opening like 200 remote images. I assume this would work with normal images as well.

since mine are remote I loaded via XHR then converted to b64 but you could easily do the same thing pre DOM render with node, generate a style sheet with your images embedded on the fly so you don't have to update anything when you modify the images. and inject it into the DOM.

Any progress/ideas anyone?

@JustASquid Could you upload a sample to reproduce the issue?

@ghostoy The export is provided in the original post - were you after something else?

@JustASquid Sorry. Forget that.

Browsers have a max number of connections per hostname (http://www.browserscope.org/?category=network), and that will naturally cause the image loading to be staggered. This limit doesn't seem to apply to local resources. @JustASquid you could try serving the images via http/localhost from the node side; it sounds backwards but might resolve the issue.

@ricardobeat

I don't have very much knowledge in this area, but does this explain why it will work in Chrome but not nw?

Basically since I'm using an engine I'm pretty much locked out from making changes to stuff like the image loading. The engine developers are convinced it's a nw.js bug so I really need to know if this is something that nw can fix or if it's something that needs an engine workaround.

@JustASquid I don't know the internals of nw, so this is just a wild guess. You should be able to change the image URLs to use http://localhost instead of relative paths, without touching the engine code. A quicker way to test this would be to just serve everything from a static http server (see #2901).

I'd like to bump the issue - while ricardo's solution may work, I don't have the internal know-how and/or engine access to implement a workaround as suggested.

It's been over three months and I'm getting very close to the planned release date of my game. I'm very worried at the moment that I'm not going to be able to make launch.

@rogerwang is there anything we can do?

This should be working with latest version now.

In 0.13 we changed to an optimized architecture so more features can be supported, see http://nwjs.io/blog/whats-new-in-0.13/ and it's good for keeping up with Chromium upstream -- we released with Node.js v6.0 and new Chromium versions within 1 day after upstream release.

The new version would fixed many issues reported here and we're scrubbing them. This issue is closed as we believe it should be fixed. Please leave a message if it isn't and we'll reopen it.