My best guess is that Chromium's mediocre memory management system (Garbage Collector) isn't doing the job when it's supposed to.

NW.js allows us to expose the garbage collector and trigger it on demand to instantly unload things from memory.

You can find steps to expose GC in my NW.js Roundup, feel free to test out How To: Force GC To Instantly Unload Audio From Memory and share your results in here.

(It's not just unloading audio by the way, it's unloading everything in the "waiting line" which is mostly just audio.)

TheRealDannyyy

Unfortunately, I still got the same result.

Just in case, I uninstalled old nw.js and then installed the new one.

I made a new fresh project and tested what you wrote before with win7 and 10.

Here are the exported file and Capx. I used r247 and nwjs26. The resizable option is unchecked.

Exported file https://drive.google.com/file/d/0B1SDO1 ... sp=sharing Capx https://drive.google.com/file/d/0B1SDO1 ... sp=sharing

I'm curious there are other people cannot reproduce the issue or not.

If that's the case, there might be something wrong on my end.

I can reproduce it using your example, that's the strange thing about this. When I open the example and export it myself, I cannot reproduce it at all so something must be wrong with your version of NW.js I assume. (Using NW.js v0.26.0, Windows 7 64bit on a Desktop PC.)

Can you please completely remove NW.js manually and install the most recent version from Scirra's page?

Maybe also remove the manifest files and replace them with "reset" ones found in the How To: Add Chromium-Args & JS-Flags section. (Backup your manifest files just in case.)

This is another question that I had in the back of my mind for quite a while now, I'd very much appreciate a response from someone with knowledge about web extensions/addons. General feedback or links to articles are welcome too.

Is It Possible To Workaround Web Limitations using Web Extensions?

Construct 3 is doing well and getting better on a weekly basis thanks to great content updates. Unfortunately there are still some missing features like instantly previewing in different browsers (like NW.js), which can currently not be implemented because it requires local-file access.

I'm sure there are many more examples but to get to the point of this topic, could an official Construct 3 web extension give Construct 3 the necessary permissions in order to make features like the mentioned one possible? When talking about web extensions, I'm mainly talking about "addons" that can be found in browser specific web stores like Chrome's Web Store or the Firefox Marketplace.

I've recently created this idea regarding Memory Management which might be relevant.

It's also addressing the issue of the currently not customizable layout-to-layout loading process that is causing a lot of trouble for the more advanced types of games, which unfortunately even the recommended 3rd party unloading plugin currently can't deal with.

taker7 I cannot reproduce this in the latest version of NW.js on my end (while using no workarounds at all).

Could you please check it out yourself and confirm if it's indeed fixed or not?

My two other workarounds for the mousepointer issue and instancing issue are both no longer working, meaning that I won't update this topic anytime soon.

Sure, here is the capx.

https://drive.google.com/file/d/0B1SDO1 ... sp=sharing

The posts about the bug here can be a reference point for people struggling from it.

I hope either we find a workaround or the chrominum team fixes the bug.

quote]

I think it's been a problem for a while. https://github.com/nwjs/nw.js/issues/1712

Thanks for the file and further information about this. Will look into possible workarounds soonâ„¢.

I'm currently waiting for the next stable NW.js release, which usually comes out a day or two after the stable Chromium update.

Judging by their calender it will be released on the 17th, will update this topic with a couple of other minor workarounds soon.

I did the tests with nwjs 0.25 both Win7 and 10, resizable and non-resizable.

...

The same result refers to the post I did above.

So it affects somewhat win10 to set window size through the plugin.

To be clear, I did "System:set canvas size to NWjs.WindowWidth x NWjs.WindowHeight" as the manual setting.

If that's not what you meant, please let me know.

Hmm... that's bad. I have no Win10 machine but I can reproduce it on my Win7 and 8.1 machines so the OS doesn't seem to be at fault here.

Could you please upload the latest projectfile (capx) so that I can look into possible workarounds on my end.

I will give you an update in here if I find something that works. For now we gotta hope that the Chromium Dev's do their work.

Thank you for leaving the comment, TheRealDannyyy

So I investigated the issue with C2 r247, NW.js 0.25 and both win7 and win10 64bit.

Here are the exported project.

...

So actually the resizable does work with Win10 and it gives the closest result with win7.

I'd say the workaroud with nwjs 0.25 is using the resizable option, though I'd like to use with non-resizable windnow.

I wonder why this resizable option does affect the issue.

Surething, always gotta push the Chromium Dev's a little so that they actually do something about it.

It's safe to assume that the window border is somehow at fault for this. Maybe we can find a way to workaround this issue.

Could you try out the following things on your end and share the results please (not all at once):

• Disable "high-DPI display" in your project settings
• Set the max/min window size using the NW.js Plugin (also try this with #3 if required)
• Manually resize the window on start of the 1st layout using the NW.js plugin

(No need to upload and share the files, just sharing your results is fine for this one.)

Hi, I recently found this thread.

I'd like to share the bug I found ages ago which is about window size issue.

In short, the bug is about window size doesn't match with an intended size.

For example, if you set the size as 640 x 360 on C2, the EXPORTED(not preview mode) project give you 651x366.

The actual value may vary depending on NW.js version.

If you want to know more about it, please check this two threads:

https://www.scirra.com/forum/exported-nwjs-window-size-issue_t185331

https://github.com/nwjs/nw.js/issues/5337

I've updated what I've found a couple of time on the C2 closed bug one.

Lastly, If anybody could share some workaround beside what I found, I would appreciate it.

Thanks for sharing this in here.

It's not looking good though, the Chromium Team seems to be ignoring this bug for almost a year now, which is always a bad sign in my experience. I've responded to the Chromium thread and I'll add it to the list of Github bugs.

Are there any reliable workarounds for this?

Please include the most recently affected NW.js versions, if you tested them out already (main versions are good enough, no subversions).

Your example doesn't use a 1px transparent border, so you're not making the right comparison. Edit the sprite, press crop (which adds the 1px border), and try again.

Wow, you're 100% right about this! I thought that Construct 2 did that on its own, my bad.

This explains why some of my in-game graphics looked terrible, just had to manually crop them after importing them into C2.

Alrighty then, no need for multisampling at all! This is much better in comparison to demanding antialiasing.

Thanks again and I hope that people reading this won't do the same mistake and always crop their sprites after importing them.

The closest I know of would be:

Not sure if it qualifies as multisampling, but there is some sampling going on.

Otherwise a shout out to Gigatron to see if he might have one.

Thanks for the link and general information about WebGL effects. I checked it out and it seems to be some kind of "post-processing" effect and not really what I'm looking for.

Nonetheless I'll consider asking Gigatron about this and if it's possible to somehow antialias using WebGL effects.

It looks fine with a 1px transparent border. I don't see what antialiasing would add to this. Can you compare with a screenshot to show what you mean? Here's what it looks like today with a 1px transparent edge and no antialiasing. I can't see how the quality of this could be better.

*image here*

Also thanks to you Ashley for taking your time in order to respond to my questions.

The 1px transparent border workaround comes close to antialiasing without a doubt but it's still worse in certain cases.

Instead of making the case for or against antialiasing using screenshots, I'd rather like to provide two practical examples found below.

These tests are fairly simple, they require the latest versions of Construct 2 and Construct Classic.

Download Construct 2 Example | Download Construct Classic Example

Steps to reproduce both examples:

• Start the preview
• See that the blue box rotates slowly at about 10 degrees per second
• Notice that Construct Classic delivers smoother edges (if 8xMSAA is supported)

Here is a screenshot of my observation as well, although I don't really see a point in sharing screenshots of static sprites.

(Problem Solution: Always crop your sprites inside the image editor if possible!)

Wouldn't it be just as easy to use an fx?

If you have such an effect which is doing true antialiasing (not just softening/bluring), please share it in here so I can give it a try.