Android ManyTeapots sample is slower in WebGL than native app |
||||||||
Issue descriptionVersion: 54.0.2826.2 (Official Build) dev (64-bit) OS: Android 6.0.1; Nexus 5X (the performance issues were mainly reproduced on a Nexus 6 however) What steps will reproduce the problem? (1) Build and run the Android ManyTeapots sample from this workspace: https://github.com/njuwangchen/teapots_wasm_porting (2) Run the WebGL port of the same sample from app/src/main/webGL/webgl-teapots.htm ; enable port forwarding to the Android device as necessary. What is the expected output? Expect the two samples to run at roughly the same frame rate. What do you see instead? The native application runs at roughly 60 FPS (note, not using instancing), but the WebGL application struggles to reach the same frame rate. Intern clarkchenwang@ and I gathered some traces which can be found here: https://drive.google.com/open?id=0B5_ZxOyw_pEDTVB2QkY4dVNMV1U A couple of interest are: trace_webgl-teapots-512-fullscreen.json trace_webgl-teapots-512-windowed.json These two compare rendering 512 teapots both into a canvas on a web page ("windowed") and taking the canvas element fullscreen. trace_webgl-teapots-64-windowed-30x40.json trace_webgl-teapots512-windowed-30x40.json These two compare rendering to a very small canvas on the web page, but 512 teapots vs. 64. There's no reason WebGL shouldn't be able to render 64 instances of this teapot at 60 FPS. A lot of time seems to be spent in setting up the layer tree and compositing this sample. Perhaps something's wrong with the minimal HTML in this test case. Any suggestions for corrections are welcome. Note again: most of the performance issues, and all of the above traces, were gathered on a Nexus 6 rather than a 5X. The Nexus 6 is an older device and seems to reproduce the performance problems more easily.
,
Sep 2 2016
,
Sep 3 2016
kbr@ you're right the CC processing time trace_webgl-teapots-64-windowed-30x40.json looks really surprising, given what the content looks like. Singling out a frame - 0.701 ms WebViewImpl::updateAllLifecyclePhases 0.818 ms LayerTreeHost::UpdateLayers::BuildPropertyTrees 2.150 ms Commit & Prepare tiles 0.958 ms Complete tiles & Activate 1.185 ms Draw & Swap kbr@: Is there a built version of the app shared anywhere?
,
Sep 7 2016
Sorry, I haven't built the app myself, only looked at it on Chen's phone. Let me know if you need me to help build it.
,
Sep 15 2016
I've been working through the build instructions at https://github.com/mtrofin/wasm-android-demo and have a pull request up with some fixes. I've built the app locally but don't have a cable to install and test it. Will update this bug tomorrow with a Google Drive link. In the meantime, upgrading this to P2; further investigation, and a fix, are desired in a timely fashion.
,
Sep 15 2016
I looked at the traces and didn't see anything out of the ordinary. It certainly looked like there was a lot of time being descheduled, more than anything. I think I would need more information about the page itself. I would expect building property trees / commit / preparing tiles to be more expensive when there were lots of layers. It's hard to tell without a frame viewer trace how many layers there are and if those costs are reasonable for this particular page content.
,
Sep 15 2016
Here's a folder containing the built (debug) apk of the native Android app: https://drive.google.com/open?id=0B5_ZxOyw_pEDclQxUEhCVGVoSDQ I've tested it on a Nexus 5X. Install with: adb install -r app-debug.apk It's called "More Teapots". Even though it's a debug build (it doesn't seem easy to produce a self-signed Release binary) it still runs at 60 FPS for 512 teapots. More updates shortly regarding traces of the web page.
,
Sep 18 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 19 2017
,
Sep 20
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 21
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by sunn...@chromium.org
, Aug 30 2016