If you have concerns about mobile performance, please, please, please:
- make a .capx
- make performance measurements
- share the .capx and measurements
It is incredibly frustrating to read long threads about supposedly poor performance and yet not be able to do anything at all about it. On page 4 of this thread, all I can do is shrug and say I don't see what you're seeing, apart from maybe acknowledging that Chrome has had a rough patch of bugs which has affected smoothness and performance (and NW.js and Crosswalk inherited that), which is Google's responsibility, and not to do with Construct 2 or its engine. I saw another thread like this, something like 20 pages long, and I got a single .capx out of it. I profiled it and managed to make some improvements for the next build. That was a useful improvement. But I cannot make performance measurements and code optimisation improvements from complaints on the forum alone. If you really want to make a difference, the conversation about performance needs to be focused on real examples with actual measurements, not just talking about it.
Often the next argument is "you depend too much on third parties like Chrome", followed by a suggestion to use a different third party engine like HAXE or some other library, which could equally cause problems, and IMO is more likely to since few of them have the backing of a billion dollar corporation with thousands of engineers. No software is perfect; everything has its issues; the fact one platform has issues is not an argument to go through an incredibly disruptive technology shift to another platform that has fewer development resources going in to it.
Often then people send us .capx projects which clearly hit hardware limits, for example they hammer the GPU fillrate incredibly hard, or use tons of intensive shader effects. Native apps use the same GPU, so a native engine won't save you: it's still the same hardware, and will still be just as slow. A native engine will only help if your game is CPU-bottlenecked. Of the CPU-bottlenecked projects we see, often they do crazy things in clear contravention of our performance tips to an extreme extent. Badly designed games will still run badly no matter which technology you use. I don't mean to blame everyone here for designing their games badly, but of the .capx files I am actually sent, this is frequently true; if you think this is the case even with a well-designed game, see my request at the top!
I had the opportunity to profile The Next Penelope - one of the most ambitious games developed with C2 - and look for any performance bottlenecks. It was running very well and the engine was holding up great: it had a very even spread of CPU load across lots of small functions, with no obvious bottlenecks, and good overall performance. I think that at least proves that well-performing ambitious-scaled games are possible, and that there are no obvious performance deficiencies in our engine (as in the JS code we've written).
The asm.js version of Box2d should run within 1.5x as fast as native C code according to Mozilla's benchmarks, and it's still improving. Performance issues in physics games using asm.js physics are probably either due to maxing out the CPU due to too intense use of physics, or it's not actually physics which is causing the performance problem at all.
When people run in to hardware limits that native engines would also face, or even come up with some crazy game that does something like hammer pathfinding across a huge map every tick and find it eventually chokes and dies, the impulse seems to be to immediately blame HTML5 or the browsers or our engine. Of the projects I see, this is frequently unjustified. Again, please, send me real examples so I can examine them and make any necessary improvements. Make this about .capx files and measurements, not just long forum threads.