Poor 2D canvas performance

[ButzYung]

I am working on a project that uses 2D canvas intensively, but the rendering speed is very poor on Tint (tested on the node-webkit build "Runtime.exe" bundled in "trial.zip"). On normal builds of node-webkit, the rendering speed is good as if it is rendered on GPU hardware. However, on Tint, the rendering speed is poor as if it is rendered in softwared only.

Turning the background transparency feature on or off does not make any changes.

---

My PC spec:

OS: Windows Vista 32-bit Home Basic SP2
CPU: AMD Athlon 64 X2 Dual Core Processor 5000+ (2.61GHz)
RAM: 2GB
GPU: ATI Radeon HD 5450 (using AMD Catalyst 13.4)

[trevorlinton]

@ButzYung

We tested it on macosx and confirmed that 2d canvas performance has degraded for two reasons;

1. to support "click throughs" for mouse events on transparent areas. We're adding the ability to turn this feature on and off to get back canvas 2d performance if transparent mouse clicks aren't needed.
2. Currently we're based on chromium 30, it has a known bug in typed arrays degrading performance using them significantly, we'll have to bump it to fix this performance issue as well.

This will be fixed in 1.5

[trevorlinton]

@ButzYung The bump to chromium 30 will come for V1.5.5 next week hopefully, however we've fixed the 2D canvas performance issues. You can download the latest trial to see if this fixes your issues.

[ButzYung]

@trevorlinton I have downloaded and tried the latest trial. Unfortunately, it seems to break more than it fixes. Now, when background trancparency is ON, NOTHING is displayed for whatever content type, no matter it is 2D canvas, WebGL or simply a normal image (No error is produced, though. It just displays nothing on the screen). Not even the transparency and WebGL demos on Tint Compiler work (they did work on the previous version of Tint). However, everything works fine with decent speed when background transparency is OFF.

I mentioned in an issue on Roger's node-webkit repo, that in the previous version of Tint (1.4) when I went straight to use "Runtime.exe" for the first time, canvas 2D worked with decent speed but WebGL failed. But then when I tried out the compiler and then used Runtime.exe again, WebGL worked but then canvas 2D slowed down. Somehow I have managed to find the cause.

When "Runtime.exe" is executed for the first time, the following folder is created (Tint 1.4).

C:\Users[username]\AppData\Local\Tint Nov 8 2013

It is empty at the beginning, and at that time canvas 2D works but WebGL breaks (JavaScript wise, the WebGL context cannot be created).

Then, if you run Tint Compiler and run a demo or something on it, some files will be copied to that folder, mainly nw.pak and some dlls. If you use "Runtime.exe" again, WebGL now works but canvas 2D slows down. I have managed to narrow down the cause to the file "libEGL.dll". If I remove that file from the folder, the condition will go back to that canvas 2D runs smoothly but WebGL breaks.

In the case of the latest Tint, similar things occur. When "libEGL.dll" is missing in that folder (TintNov 22 2013), WebGL breaks. However, the canvas 2D case is reversed (ie. canvas 2D runs faster when "libEGL.dll" exists, altough the speed isn't that bad when it is missing, and is still significantly faster than the slowdown case in Tint 1.4).

I hope these information help solve the issue.

---

PS: In ALL mentioned cases, I am testing on Vista standard theme (eg. DWM activated). On Vista basic theme (eg. DWM deactivated), no background transparency ever works (nothing is displayed in most cases), except when using the latest Tint trial, basic web elements (no canvas no WebGL) with background transparency seems to work.

[trevorlinton]

@ButzYung We're still looking into this. It sounds as if you're using the runtime directly without Tint Compiler; The DLL's you refer to are necessary for proper rendering. You can either package and distribute them with your application next to Runtime.exe or use the Tint Compiler to ensure they're included.

As for the transparency not working we're digging deep into this. As we've heard from our experts and Microsoft that transparency is a bit of a "touchy" feature. Chromium has about 15 paths it can take to render a webpage depending on a variety of conditions. We're building out a solidified unit test system and ensuring we can support transparency across the board. We're looking at:

1. Windows Vista, 7, 8, Vista (no-DWM), Mac OSX 10.6, 10.7, 10.8, 10.9
2. Supporting both D3D/non-D3D support
3. Hardware acceleration vs. software rendering
4. Compositing vs. non-compositing support
5. Canvas2D support
6. 3D CSS transform support
7. WebGL support

The math on this works out to 67 use cases we need to create, pass and track. So this may take a bit.

[trevorlinton]

Fixed, update will come with 1.5.9

[trevorlinton]

@ButzYung We recently updated the transparency and built out test cases for all 67 rendering paths. V1.6. is working in all test cases now. Can you try out the newest version and let me know if you continue to have issues?

Thanks,
Trevor

[ButzYung]

@trevorlinton The new Tint v1.6 doesn't even start (both "Tint Compiler.exe" and "Runtime.exe"), with an error popup saying the application is incompatible with my version of Windows.

[trevorlinton]

@ButzYung We moved to a 64-bit architecture, are you still on 32-bit?

[ButzYung]

@trevorlinton Yeah... still 32-bit Windows. So Tint will be 64-bit only from now and on...?

[trevorlinton]

It's fairly easy to have a separate build/config toolchain for 32-bit.

Hopefully it won't be too difficult to add this into the compiler, essentially have it spit out a 64-bit and 32-bit executable. The actual compiler can be brought back to 32-bit as it doesn't have significant performance benefits from being 64-bit.

I'll see if we can get this option added in the next few days.

[ButzYung]

Although 64-bit is becoming more and more common, 32-bit support is still important IMO, especially since you guys still plan to support older OS like XP and Vista. Most people who still use XP/Vista these days are probably still on 32-bit (like me).

[trevorlinton]

@ButzYung I agree, we'll get 32-bit support added back in ASAP, there's actually quite a few people to my surprise still on 32-bit systems.

[ButzYung]

You will be surprised by how many people are still using XP here in Hong Kong and China lol

[trevorlinton]

@ButzYung We've moved the compiler back to 32-bit for Windows. In the future we'll offer a 64-bit and 32 bit option. Please let me know if you have any other issues.

[ButzYung]

@trevorlinton It seems things are getting a bit "complicated" in this version...

---

Using Vista standard theme (ie. DWM on):

With background transparency on, canvas 2D/WebGL content displays, but with a solid black background. For other content type, background transparency works somehow, but there is still a white blackground flickering behind (the frequency is somewhat related to how often the screen content is updated).

With background transparency off, everything works fine.

---

Using Vista basic theme (ie. DWM off):

With background transparency on, NOTHING is displayed for whatever content type (basically, transparency never works in basic theme even in older versions of Tint, though).

With background transparency off, everything works fine.

---

About "package.json" file:

It seems the "frame" parameter of the "window" object is not working in this version of Tint. It is always on even when you set it to false (ie. the window always has a frame border), except when "transparent" is true.

---

About "require('nw.gui').App.argv":

If I open "Runtime.exe" as a command line (eg. Runtime [app path] [custom para 1]), "require('nw.gui').App.argv" returns both [app path] and [custom para 1] as the arguments, while only [custom para 1] is returned in older versions of node-webkit and Tint.

[ButzYung]

@trevorlinton Forgot to mention that "showModalDialog" works now.

[trevorlinton]

Hi @ButzYung I'm reopening this bug, i'm hoping to fix this within in the 1.6 time frame, however it may be pushed back into 1.7 as we have some pressing UI needs to get fixed.

-t