Don't know what to think.

[agamemnus]

I really like the idea of copying the engine into the program/app for stability purposes. After making some CSS changes and other html changes, my jigsaw game (just on 4.4.2 Android Webview, Note 2) actually runs faster and better than Webview+ on many measures. Not using Webview+ this will greatly limit my audience since only the most recent Android versions can run it well.

In Webview+ I am contending with the earlier mentioned scrollbar corruption issue. The refresh rate starts out not too great and rapidly (a couple of minutes) ends in sub-1 FPS before a final crash. Note that there is no such slowdown in 4.4.2 Webview. I already mentioned the shading speed issue which seems to be a Chromium bug (perhaps), and the slowdown to crash issue is something Chromium also has, but not to such an extent.

Edit: I compiled with Crosswalk, and although the game doesn't slow down and then crash, there are (worse) flashing issues and speed issues as well. I guess a lot of it has to do with Chromium doing something totally horrible after I use CSS scaling (-webkit-transform) and Javascript to scale the page to the viewport.

A curious item is that if I start the profiler in Chrome while remote debugging, the game actually runs FASTER and does not degrade.

I guess the most pressing need for me personally is instructions or a way to set up the target Chromium version for the Webview+ build, if indeed most/all of these issues are (Chromium) regressions.

I'd like to once again invite you to look at my latest APK running Webview+, which I can email you if you'd like.

[ludei]

Hi Agamemnus

Thanks for the information, what do you mean by "set up the target Chromium version for the Webview+ build"?

Thanks in advance

[agamemnus]

I mean using a specific Chromium version to build the webview and Webview+.

[ludei]

Currently there's no possibility, as we deliver a single version of webview+.
In the short-term we plan to release 3 versions of webview+: based on stable version, beta and canary. We still need more testing with that.

Regarding your rendering problems, the webview+ has disabled the flag of blacklisted GPUs (ignore-gpu-blacklist). Maybe your device is included in the following list:
http://src.chromium.org/viewvc/chrome/trunk/src/gpu/config/software_rendering_list_json.cc

[agamemnus]

I have a few more comments. As a reminder the game is a jigsaw puzzle game (which I have published on Google Play as of yesterday!). I am compiling with Crosswalk (needed to try the latest Chrome version!) but most of this applies to Chrome 37 and Webview+ as well, so it does seem to be basically some collection of Chromium issues.

1. In Chromium 37, my game seemed to have a ton of memory leaks. Inexplicably, setting a ton of variables to null (basically all local variables representing canvas elements) helps prevent the memory leaks. This seriously shouldn't happen and I am not sure why it is happening.. perhaps a hook too many in the debug system. I can 100% confirm this behavior, but I am unable to create a test case as of yet.

2a) I think more memory is allocated to Chrome, which somewhat reduces above mentioned memory leak issues which I notice right away in Webview+.

2b) It seems that the Chrome browser does have certain settings that might help in terms of speed as compared to CocoonJS and Crosswalk, but I am not exactly sure yet what those settings are.

3. Again I am not able to reproduce this anywhere except my game (which makes convincing the Chromium devs difficult for some reason...), but replacing requestAnimationFrame with setTimeout actually massively increases my FPS on Android. This is visible on the PC but not to a great extent. Can't repro in Firefox so it seems to be a Chromium issue.

4a) Reducing the amount of layers and canvas elements attached to the DOM seemed to help with speed and rendering, but it considerably bludgeoned my code. I have now a single large canvas element on the document body, although with significant amounts of DOM GUI elements besides the main area, drawn above the canvas element.

4b) I have a function that does css transforms on the main DOM element of the game to keep the game sized and centered appropriately. This does come with potentially some compositing bugs, such as extremely blurry textures and again slower speed.

5a) I still can't tell whether the game is hardware accelerated. It's a Note 2 with "1.6 GHz quad-core Cortex-A9". Turning off hardware acceleration in my Cordova project seems to do nothing, but maybe it's still somehow turned on...

5b) My phone runs complex 3D games with ease, but has trouble with a few 2D elements on Chromium... Enabling the visual fps switch shows that fps can dramatically slow down. It also shows extremely inefficient gpu memory allocation for any sort of complex 3D CSS operation and for canvas operations in general.
I get a huge burst of GPU memory usage going near 60 megabytes in my level start, and that is way above any sort of rational expectation. After the burst the GPU memory usage goes to between 1 and 4 megabytes -- which is below my expectation, and it is actually reduced when I "pick up" a piece, which creates a temporary canvas and runs canvas refreshes.

I have had a lot of inexplicable debugging moments getting this to work in Chromium. Hard to say if the ease of the DOM, instead of putting absolutely everything in a canvas was worth the anguish. It does work extremely well on my Windows 7 laptop, by the way, as can be expected...

Others working on games that use anything more than trivial CSS animations have also told me about FPS drops ("stutters") in Chromium, though this may be related to missing flags or too many flags in Cordova Crosswalk / Crosswalk Cordova.