google
Android UI not responding when loading larger GLB model
⚠️ Issues not using this template will be systematically closed.
Describe the bug
When loading larger models (over 8K entities) ModelViewer#loadModelGlb blocks the UI. Calling this function in a different thread results in This thread has not been adopted when executing ResourceLoader::Impl::computeTangents
Engine has been created from main thread so as per the below comment in Engine.cpp,
// we're assuming we're on the main thread here.
// (it may not be the case)
mJobSystem.adopt();
only the thread from which the Engine is created will be adopted by the JobSystem which eventually blocks the UI when loading larger model
To Reproduce Steps to reproduce the behavior: Loading a larger model hangs the entire UI, can't exit out of the screen
Expected behavior UI should not be blocked
Desktop (please complete the following information):
- OS: Android
FEngine resolved backend: OpenGL
QUALCOMM build : 8e5405b, I57aaec3440
Build Date : 05/21/21
OpenGL ES Shader Compiler Version: EV031.32.02.10
Local Branch : mybranchebba1dbe-451b-f160-ac81-1458d0b52ae8
Remote Branch : quic/gfx-adreno.lnx.1.0.r135-rel
Remote Branch : NONE
Reconstruct Branch : NOTHING
Build Config : S P 10.0.7 AArch64
Driver Path : /vendor/lib64/egl/libGLESv2_adreno.so
PFP: 0x016ee190, ME: 0x00000000
[Qualcomm], [Adreno (TM) 630], [OpenGL ES 3.2 [email protected] (GIT@8e5405b, I57aaec3440, 1621601959) (Date:05/21/21)], [OpenGL ES GLSL ES 3.20]
Smartphone (please complete the following information):
- Device: OnePlus 6T/6GB RAM
- OS: Android 11
Additional context Sorry couldn't attach the glb file as it is confidential
UI is not blocked when I create the ModelViewer instance (& so the Engine instance) in Executors.newSingleThreadExecutor() & call modelViewer.render from the same executor. Is this the right way to unblock UI or is there a downside in creating ModelViewer in a non-main thread?
Oh when I back out of the screen I get this error,
Precondition
in shutdown:444
reason: Engine::shutdown() called from the wrong thread!
because ModelViewer destroys the view in addOnAttachStateChangeListener so I guess it is not as straightforward as operating modelViewer on a non-ui thread
@romainguy would you recommend maintaining a copy of ModelViewer ?
@mbalajee we faced the same issue as you do. Are you aware of any workarounds for the issue?
@romainguy @pixelflinger this issue is blocking us from adopting this library in production. Do you have any suggestion for this performance issue?
@innolight Yeah we ended up using Filament in a different thread from Android side. All calls to filament must be executed on the same thread. So UI is not blocked while Filament does its job initially.