Poor performance in Android Webview when using Construct game engine.
Reported by
nbav...@gmail.com,
Sep 6
|
||||||
Issue descriptionSteps to reproduce the problem: 1. Open the APK and observe the poor performance on many Android devices What is the expected behavior? APK performance should be as good as chrome performance. What went wrong? We are receiving really poor performance in Android Webview when creating APK using Cordova in Construct game engine. Some of the affected devices that were reported over time include: Galaxy note 4, LG G Stylo, Samsung J3, Samsung A5, Lenovo Tab 4, Nvidia Shield K1, Asus zenfone 2, Samsung Galaxy S5 Neo. What is even more weird is that the performance improves when running the game in Chrome (Not the APK). When APK is created the performance is far worse than running remote preview in Chrome. Using Samsung Galaxy Tab 4 10.1 (Webview version: 68.0.3440.91), when opening ‘Endless runner’ under Templates in Construct 3 (https://editor.construct.net/r115/) or 2 and running it on the tablet using chrome, the FPS stays around 60. However, when creating APK the FPS does not get over 47 and it constantly stutters. APK with FPS counter: https://www.dropbox.com/s/18sbg1iwdrzv2m9/Autorunner-debug.apk?dl=0 Did this work before? N/A Does this work in other browsers? N/A Chrome version: 68.0.3440.91 Channel: stable OS Version: 5.0.2 Flash Version:
,
Sep 6
Issue 881173 has been merged into this issue.
,
Sep 7
,
Sep 7
Tested this issue on Samsung Galaxy J7 and Pixel 2 using 68.0.3440.91 and 71.0.3544.0 and observing FPS as 59/60 only. TE do not have above devices mentioned[Galaxy Note 4 is not working], hence routing it to MTV for further help in triaging on zenfone 2/Not 4. Thanks!
,
Oct 1
,
Oct 2
,
Oct 3
Tried on a samsung galaxy tab 4 10.1. Looks like the whole thing is swap bound. Each eglSwapBuffers is taking close to 15ms already, which is most of the frame budget already. The problem is not as severe on chrome because chrome owns the surface its drawing into and has entire control over scheduling GPU work. Webview doesn't have that luxury, and there is nothing webview can do here.
,
Oct 15
boliu@ - can you explain exactly what's going on here in some more detail? Is there anything the app can do to help performance? Construct users sometimes complain about WebView performance and it's difficult to understand the reasons why, whether it is a broad issue affecting many devices, and if anything can be done about it.
,
Oct 15
Webview and chrome do not have the same graphics pipeline. Chrome renders web content into a surface that it created and owns, and has complete control over scheduling GPU work. Webview renders web content into the surface that the rest of java views draws into; that surface is created and owned by android side, and webview only gets callbacks of when it should render, so webview does not have control over scheduling and does not get much feedback on the scheduling. Also webview exercises more gles APIs than chrome does for compositing, which possibly some drivers are slower at them. It's not clear what exactly is happening here, but symptom is swap is slow. There isn't much apps can do to influence this. Chrome custom tabs / pwa is the way to go if you want to use chrome's rendering pipeline and still look like an app.
,
Oct 16
AFAICT Chrome Custom Tabs always show additional browsing UI, making them unsuitable for a fullscreen app, and PWA cannot be hosted in the Google Play store. So WebView is a key part of Android publishing. It sounds like the problem is mysteriously slow GPU drivers on some devices. Is that a reasonable reading of the situation? |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by sizzga...@gmail.com
, Sep 6