C2 performance still depressing

megatronx have you ever reported this behaviour with a real bug report? It seems odd that this shouldn't be fixable, especially if there is a 3rd party plug that does it right.

Well, I didn't think of it as bug, until you mention it, but just as a bad programing. Maybe even assumed that it was only problem due to my events, and since there was instantly working alternative, I just forgot all about it. I also thought people might have known about it! I don't really know why I assumed that.

All basic behaviours should work. If you have one of those rare and reproducible cases where one doesn't, *please* report it. It's the only way to improve things

I don't use platforming in my game and I don't have any noticeable jank right now.

So The Next Penelope runs great - doesn't use platforming. All of the people complaining are using default platforming behavior. That's what I'm taking from this

Well you didnt read the OP. The thread has been hijacked somewhat i feel

I'm on the C2 boat since 2012, developed two projects on it, one really (and maybe too) big and one quite small and simple. I putted them on hold last year due to the lack of a real monetization support (at the time there was only the infamous ludei->mopub->admob thing with ridicolous fill rates and entire days of broken servers) and checked them from time to time to see how the html5 ecosystem was improving.

What puzzles me is that my apps keep loosing performance everytime I came back checking them.

There's one project (the bigger) that worked more than decently on devices really weak by today standards (with X-Walk performing even better than Ludei's Canvas+) and now, without changing anything in my code since one year, is struggling on a Nexus 5 and, despite its heavy optimization for mobile devices, even on my desktop which is quite a beast of machine.

Unfortunately this is related to the enormous mess the chromium team has done recently and, since chromium is packed in every serious exporter we have, the situation is really depressing both for desktop and mobile developers.

For example here's a link with some benchmarks runned over various chromium version.

https://code.google.com/p/chromium/issues/detail?id=456507&q=fps&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

Although the OP of the linked post is blaming D3D binding and he's talking about the WebGL renderer, I can assure that the regression curve is basically the same on Android (so there must be a different culprit than D3D) and affects also Canvas2D performance (Maybe in a minor way, and that's probably why I found today some post on this forum claiming that Canvas2D seems more consistent than WebGL on some games).

At least mobile developers have cordova/cocoonjs/canvas+ integration at the horizon... sounds strange saying this in 2015 but with the chromium suicide, cocoonjs/canvas+ is now again the state of the art of HTML5 mobile performance (but I've been burned a lot of times before, so I become ultracareful with Ludei's announcements)

Well you didnt read the OP. The thread has been hijacked somewhat i feel

It sure has! Lots of valid bits flying around though.

Just commenting to keep these type post at top - they need to be known and addressed - in fact should be stickied!

Just commenting to keep these type post at top - they need to be known and addressed - in fact should be stickied!

I think I agree that there should be something stickied but maybe just a locked thread with the sentence "Eventually everything will work out."

It works great with all those fans who leave negative reviews on Steam, YouTube, and Twitter for engine bugs I can't fix or even reproduce in any of my testing computers ; )

I don't know if this is relevant to performance or not, but Ashley posted this recently on his twitter:

[quote:3202i0vo]Sounds like there is finally consensus about canvas rendering from workers with OffscreenCanvas: https://wiki.whatwg.org/wiki/OffscreenCanvas

Would need a runtime rewrite to use that though...

[It would mean that the] entire runtime could run in a worker, unaffected by any main thread jank. Realistically this is a post-C3 project.

I'm guessing that means our games would utilize more cores? I don't remember how many are being used, but considering 48.8% of Steam users have 2 cores and 48% have 3+ cores, that might be good.

— that'd be sweet, and since Construct 3 isn't out yet I would really, extremely, very much like it to take advantage of something like that and replace the runtime instead of just waiting until C4 comes.

I'd rather wait an other year or so for C3 if I have to to get these kind of improvements.

It might help a bit to run the engine in a worker, but I wouldn't expect it to be a transformative improvement. Running the engine on the main thread means it contends with other browser work happening on the main thread, but browser developers already work hard to keep the main thread as free as possible (by making the browser do its own work in other threads - already using other cores if available - see this blog) specifically so there's as much time as possible to be spent running JS code. I don't know, I'd guess at maybe at best a 10% improvement running in a worker. As the blog post mentions, a nice thing about browser engines is they already split work across cores where possible.

10% sounds like a great boost, if it's the difference between even 59fps and 60fps it may be all that's needed to remove the strangeness that occurs in platform behaviour.

spongehammer

[quote:35210fq0] I dont want to start another long debate about what Scirra should or shouldnt do as there are a number of those threads already running.

So, if this isn't about what you want Scirra to do.. what do you want? (Serious question)

Ummm yeah. I actually don't get that too.

Irbis

Read the thread, I already answered.

The thread was simply a statement about how i felt when i went to start a new project then got reminded straight away about the poor performance of C2/Chrome/NW.js

There was no intention to start a long debate about it because we have heard it all before and nothing gets done.