Hello any updates on this? It's 2018 now..

It's looking very promising this year, a lot of progress has been happening over the recent months. Experimental support is already included in Chrome M65 and only requires a js-flag to be switched. (I've been looking into NW.js support through chromium-args but it's currently bugged.)

If you want to test out controller feedback yourself, please do the following:

• Make sure you have a good controller that's supported and Chrome M65 or newer
• Go to chrome://flags/#enable-gamepad-extensions (URL) and enable "Gamepad Extensions"
• Go to this feedback testing project made by Armaldio
• Press any button on your controller (if recognized it will be displayed on the top-left corner)
• Fill in the required information and click on "rumble" (e.g. 0 | 1 | 1 | 1000)

We're keeping an eye on feedback support and will surely create another topic with more info and even provide a custom plugin if needed.

I think --ignore-gpu-blacklist would prevent the software renderer ever being used anyway. I guess if you literally don't have a GPU (or it's a headless system or some such) then it actually should fall back to the software renderer, so I guess it's better to remove --disable-software-rasterizer anyway. I think those systems are pretty rare, and surely nonexistent amongst gamers, so it's pretty academic. So it should be fine to just delete that flag, which is what the latest betas do.

Thanks for the info!

(Quick update: I've changed the "default" package.json files available in this topic with the most recent files that come with r256.)

TheRealDannyyy I noticed that when I use v0.29.0 and C2 R256 adding this arg

--disable-software-rasterizer

Causes rendering problems and the steam overlay is not loading, I actually don't remember why I added this arg, it was from something I probably read here before, but I can't locate any reference to it in your original post.

Do I need this for something?

This arg was there from the beginning and the removal of it is basically what the recent beta update did (maybe also some other minor runtime changes). As Ashley stated in the github Issue, this arg was mainly in place in order to ensure that we don't get software rendering. Important to note is that NW.js added Swiftshader support in v0.25.3 for Linux and Windows (no OSX support?), which lets you use WebGL even on hardware with incapable GPUs and I assume does the same job as the arg.

In short, the mentioned arg didn't disable software rendering because of a bug and also disabled Swiftshader support, causing all sorts of problems in our games. From what I can tell this has been fixed in v0.29.1 and this might just be a temporally change but I personally don't see a reason to use this arg in the future because of Swiftshader support.

This is all fairly complicated for me as well, maybe asking Ashley himself about all of this would be better if you experience any major issues.

It should now be possible to use v0.29.0 without any issues if you have Construct 2 R256.

Please note that this beta update will wipe your package.json files clean, so I'd recommend doing a backup of those 3 files.

Can anyone tell me which NWjs version is the most stable and functional to use at this time?

I'm still using 0.24.0, every time I'm thinking of upgrading I'm seeing posts about things that got broken, I don't have any issues with 0.24.0, but I do want to keep it as up-to-date as possible.

Should I even upgrade or wait for 0.30.0 to come around?

By default I would always go with the most recent version, in this case v0.30.0, however currently it would be v0.28.0 judging based on bugfixes.

I'd just wait for v0.30.0 because that's going to be a good release with some beefy new features (spoiler: experimental gamepad rumble support).

I was wondering if any one is having a similar problem I'm having with NWJS v0.29.0 in which Effects are no longer working and using the fallback. NWJS v0.28.0 works fine though. Running C2 r250. (Could that be it?)

EDIT: Just to add some images illustrating the problem.

This is the base image.

<img>

There's a green background (TiledBackground) that goes over this with an Effect: Multiply. In v0.28.0 Chromium 64, it works as expected, and this is how it looks:

<img>

In v0.28.0 Chromium 65 it looks like this:

<img>

Also other effects don't seem to work as well. They simply don't show up.

I'm not knowledgeable enough to know if this is related to Chromium itself -- I tried looking for instances of rendering errors using WebGL effects, etc but couldn't find anything relevant -- so I'm not sure where the 'bug' lies. Any hints? Thanks!

[EDIT]

I've upgraded to C2 r255, but no, that doesn't seem to change anything.

That is a known issue and effects are not working because WebGL isn't running as it's supposed to. This has already been fixed in all versions after NWjs v0.29.0 but I guess Ashley is waiting for a main release (v0.30.0) before uploading the most recent working version. Currently the only options we have is to use versions before v0.29.0 or manually install the subversion from HERE.

Ah, sorry, I forgot to mention as well that this was in NW.js.

I investigated further and found this: https://github.com/nwjs/nw.js/issues/6336#issuecomment-352252411 I've been on a version a few versions back, avoiding to update in case it breaks a big project of mine. Testing v0.29.0 it seems the fix has been implemented, however, everything runs at 30 fps now (was hitting 144 fps without issues before) so I'll have to do some more testing, restart my computer and maybe try v0.28.0 too. I'll update with further findings.

EDIT:

So v0.28.0 seems to be the best solution for now if you don't wanna fiddle too much. Mouse lock works and the performance is good.

I found the reason for the poor performance with v0.29.0 (Ashley and NW.js devs are aware as you can see): https://github.com/nwjs/nw.js/issues/6498

Hopefully an updated version will be available soon that doesn't require manual handling of those command line arguments.

Thanks and good to know about the issues.

I've had a very similar problem to this with intense slowdown occurring every 30 minutes or so.

I had found a temporary fix in which I had to close any dialogues and then minimize and then un-minimize C2. ...

Same thing for me but I'm not running C2 on a laptop so it must be something else causing these slowdowns.

I'm sorry, I don't mean to troll you, I'm just describing exactly what happened last time we added a performance workaround. We add a workaround, then someone immediately asks to fix it without the workaround. ¯\_(?)_/¯

No problem. Although I can understand that people would request a quick fix because they might not have the time to wait for the whole process of isolating the bug and fixing it. Sadly this doesn't seem to be an easy one to fix.

So, just to be clear, you don't have performance measurements to back this up?

I've never seen or heard any such cases of high-DPI causing performance issues in C2 games, unless it's due to GPU bandwidth limits. The option to disable high-dpi mode in the runtime is essentially a variant of "low quality" fullscreen mode. I don't think there's any kind of parallel to the editor there, editing software does not usually come close to GPU fillrate limits, it's entirely different to game rendering.

You're right, I'm just assuming that it might be at fault and the problem is that I wasn't and am not able to test this out. I don't own a Win10 system (yet) and I don't want to cause any damage to the systems of the people that helped me out with testing so far, by manipulating the registry or whatever is necessary in order to force disable it for reproduction.

The high-dpi setting in exported games only seem to affect some systems, not all of them. All I know is that disabling it helped those systems to run the game well. It's always difficult to narrow down the main cause for performance issues but I guess the slight quality improvements when using high-dpi were too much to handle for those systems.

On a different note, I've recently received a PM by a community member and Windows update "kb4087256" seems to have fixed all of his slowdown problems. He's provided a screenshot with the updates that probably fixed it and after looking up the changes of each individual update on Microsoft's support thread, "kb4087256" seems to be the one which might be the solution to all of this. It would be great if you and generally everyone without slowdown issues could temporally remove those marked updates and test if any slowdowns occurs. If the updates are missing, I'd appreciate installing them and providing feedback if it fixed the slowdown issues.

If you mean "Override high DPI scaling" setting on Compatibility tab in C2 shortcut - I tried this and it didn't help.

In fact, I tried all compatibility settings and none of them made any difference.

If that's the case then high-dpi is probably not at fault for the slowdowns. I'd still like to get more feedback from more users before dropping this though.

Thanks for testing it out and providing feedback!

I'm a bit confused, are we not already able to turn off high-dpi scaling in the settings on our C2 projects ?

Yes but this is for Construct 2 itself and as far as I'm aware it makes use of this feature.

---

This seems to raise more questions than it answers...

Which setting, exactly?

I didn't know that - which setting has changed and how? ...

Windows 7 + Win10 (before update) / Win10 (after forced dpi update)

I assume that C2 has high-dpi support enabled by default, which could be the reason for why users started experiencing performance issues more recently and not before that mentioned update that started forcing high-dpi mode.

C2 has had basic support for high-DPI for as far back as I can remember. There's nothing we've changed on that front for a long time, and C2 should not have been using a compatibility mode, because it is natively system-DPI aware.

The latest changes were done in r229, assuming that high-dpi is indeed the cause for slowdowns it would make sense for people which experience these issues without having a Win10 system with the latest updates.

This would make the whole UI look blurry. I'm sure the next question would be "how do I make sure the UI looks sharp?"

Could you please stop being "trolly" and stop putting words in my mouth. I'm trying to have an honest and polite conversation which hopefully ends up in finding a solution to this problem. (I know you've had your fair share of bad experiences but I'm just trying to help by providing possible causes for this impactful issue.)

We already worked around the event dialog performance issue by implementing a special setting, and then the next question was "how do I fix the performance issue without using the special setting?", so it seems these kinds of workarounds are not satisfying to users.

This isn't really a request for a long-term settings option to degrade the quality of Construct 2, it would a temporally (beta) option in order to maybe find the cause for slowdowns and help you out to narrow it down and fix it. Unless of course you've found the cause already, in that case I'd really appreciate a heads up about it!

What evidence is there that this does cause the performance issue? What measurements have been made with which combinations of settings and how do they compare? I don't see any evidence at all for this right now.

That's the issue, as far as I know Win10 doesn't allow to disable high-dpi in the properties anymore (at least the community members I've asked couldn't find a way to disable it completly). Based on a more recent report about high-dpi and performance problems and the before mentioned updates in r229, which exactly fit the the affected parts of Construct 2, I thought this might be the fault of high-dpi. High-dpi is known for causing bad performance even in exported C2 games which lead to my assumption based conclusion that it might be at fault.

Ashley After doing some research with members from the community which experience performance issues with Construct 2 on Windows 10, I've come to the conclusion that "high-dpi scaling" might be at fault.

Just a quick note before we go into more detail, Microsoft decided to drop the legacy option to disable application specific high-dpi scaling and pretty much force enable it now, so I couldn't fully test if it's indeed at fault for all performance related complaints that have been reported over the recent months.

TL;DR: I would appreciate if everyone who'd like to participate in this topic, could refrain from posting raging assumption based conclusions.

As you might already know, Windows 10 more recently decided to only allow users to override the dpi setting and not disable it completely. However I found out that it's possible to set it to "Application Mode", which basically means that C2 has full control over the dpi mode. I assume that C2 has high-dpi support enabled by default, which could be the reason for why users started experiencing performance issues more recently and not before that mentioned update that started forcing high-dpi mode.

What does this all mean and why should you care about any of this?

Simple, with an added option to disable high-dpi as a whole for C2 (despite it's downsides of overall quality), users that experience performance issues could test it out and provide feedback which could lead to the conclusion that high-dpi scaling is indeed at fault for the most recent performance issues with C2 on Win10.