zendorf - perhaps you missed the posts above where it was discovered that groups actually have almost no performance impact at all - it's only while debugging that it uses a lot of CPU time.

Oh, duh - of course the debugger hits the CPU in relation to groups, it's doing tons of performance tracking and such. Yeah, in preview but not in debug mode it's down to 0.2 with 1000 groups.

jayderyu - try using the cpuutilization expression instead of the debugger.

1000 inactive groups is the same as if they're active, about 18-28.

I did another check - it makes sense that a group would use some CPU, as it's got to check if it's active or not. However, comparing against 1000 events checking if a global var=0:

5-10

It makes we wonder if they can in fact be optimized more - I don't understand much about C2 at the JavaScript level, though.

(Edit: disovered on the next page the groups high CPU usage was because of the debugger.)

Usage as percent:

No code

0.1

1000 blank base events

0.8-3.5

1 base event, 1000 blank sub events

0.7-3

1000 groups

18-28

1000 sub groups in a disabled group

0-0.5

1000 sub groups to an event that does not run

0-0.5

Weird and a bit disappointing that groups hit the performance like that. I wonder if they can be optimized somehow.

jayderyu

Regardless, they have a very insignificant performance impact if they are skipped because the parent event does not run. As such, you can optimize like so:

If unit1.count > 0

• event tree

That will skip right over unit1's code and all groups contained therein if no instances of it exist.

SeekerSK - I've gotten that too. I haven't tried tracking down the reason yet, but I'm guessing node webkit is set to too low a priority and other processes sometimes 'shove it out of the way.'

Even using what I suggested isn't a complete solution, anyway, as it won't work for people wanting to put a non-downloadable demo online, or make parts of a web page with html5.

Just... ARGH

If it's actually enabled, yes it should be faster.

If you're testing on chrome on an XP or vista computer, the chrome team decided to disable all hardware acceleration on those os's recently.

You also might have a blacklisted card/driver.

If either of those cases are true, you're getting software rendering instead, which is seriously slow.

More info:

http://www.khronos.org/webgl/wiki/Black ... Whitelists

https://dl.google.com/dl/edgedl/chrome/ ... _list.json

You can try going to chrome://flags and turn ignore-gpu-blacklist to enabled.

AUGH for crying out loud

Upon looking into it further, I discovered that the chrome team has decided to disable hardware acceleration for all systems running XP or vista. Reasoning:

https://code.google.com/p/chromium/issu ... ?id=315199

"...the short answer is that we don't have a good way to reliably

ensure that these features work correctly on XP and Vista. We've had a

number of bad bugs that went to stable users without anyone realizing (i.e.

not in our testing nor from bug reports), and fixing those bugs is very

difficult because reproducing the relatively exotic hardware configurations

involved is next to impossible. Without that good testing / feedback loop,

ensuring we don't break Chrome is difficult enough that we're playing it

safe rather than risking it.

It's also worth noting that many (though not all) WinXP and Vista machines

are old enough that they don't really benefit from hardware acceleration

features. WebGL and Stage3D do, mostly, but we use the GPU for all pages on

Win7+ and all other Chrome platforms (well, except Linux, but that'll

happen soon). If we moved to that model on XP and Vista, we take a major

compatibility risk as explained above, for basically no gain -- on memory

bandwidth constrained devices there isn't much win here. The model we're

moving to architecturally requires that Chrome is in one bucket (all GPU

feature enabled) or another (all software). Hence, this blacklisting change."

Not just webgl, also flash, video decoding, whatever. All hardware acceleration is off on those OS's. >:(

There are quite a few users still on those platforms, including me. I guess our only option is to either use an earlier version of node webkit or run the game with the blacklist disabled, but if including the argument in the package.json doesn't work, then the only option left is to try to ensure that the player doesn't run the exe by itself, and has to run it from a modified shortcut.

Kinda frustrated.

http://www.scirra.com/reputation

I sent you a pm.

Ah, cool, glad to know it's on the to do list.

Please don't make multiple threads for the same question.