dequeueBuffer: impossible de retirer plusieurs tampons de la file d'attente sans définir le nombre de tampons

123

J'obtiens l'erreur ci-dessous Android 4.4.2 Moto X 2013dans une Rhomobile 5.0.2application WebView. L'application est compilée avec SDK 19et minAPI 17.

Après quelques recherches, il semble que ce soit un problème avec Snapdragon 800 / Adreno GPU devices:

voici et voici les liens vers ce problème sur Google issue tracker

La désactivation de l'accélération matérielle n'est pas vraiment une option, car elle rend la WebView très lente.

Puisque l'erreur est:

dequeueBuffer: can't dequeue multiple buffers without setting the buffer count

Comment puis-je définir le nombre de tampons dans com.rhomobile.rhodes.RhodesActivity?

11-08 18:28:31.227: I/SFPerfTracer(238):      triggers: (rate: 0:0) (423387 sw vsyncs) (0 skipped) (0:361861 vsyncs) (2:863582)
11-08 18:28:31.328: W/Adreno-EGLSUB(4749): <DequeueBuffer:593>: dequeue native buffer fail: Unknown error 2147483646, buffer=0x61213afc, handle=0x0
11-08 18:28:31.331: W/Adreno-EGLSUB(4749): <SwapBuffers:1343>: Invalid native buffer. Failed to queueBuffer
11-08 18:28:31.331: W/Adreno-EGLSUB(4749): <updater_thread:456>: native buffer is NULL
11-08 18:28:31.346: E/BufferQueue(238): [com.myapp.myapp/com.rhomobile.rhodes.RhodesActivity] dequeueBuffer: can't dequeue multiple buffers without setting the buffer count
11-08 18:28:31.346: W/Adreno-EGLSUB(4749): <DequeueBuffer:593>: dequeue native buffer fail: Invalid argument, buffer=0x61213afc, handle=0x0
11-08 18:28:31.347: W/Adreno-ES20(4749): <gl2_surface_swap:43>: GL_OUT_OF_MEMORY
11-08 18:28:31.347: W/Adreno-EGL(4749): <qeglDrvAPI_eglSwapBuffers:3596>: EGL_BAD_SURFACE
11-08 18:28:31.347: W/HardwareRenderer(4749): EGL error: EGL_BAD_SURFACE
11-08 18:28:31.352: W/HardwareRenderer(4749): Mountain View, we've had a problem here. Switching back to software rendering.
11-08 18:28:31.478: D/qdgralloc(4749): Invalid gralloc handle (at 0x0): ver(-1/12) ints(-1/12) fds(-1/2) magic(????/gmsm)
11-08 18:28:31.478: W/GraphicBufferMapper(4749): lock(...) failed -22 (Invalid argument)
11-08 18:28:31.478: W/Surface(4749): failed locking buffer (handle = 0x0)
11-08 18:28:31.531: E/ViewRootImpl(4749): Could not lock surface
11-08 18:28:31.531: E/ViewRootImpl(4749): java.lang.IllegalArgumentException
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.Surface.nativeLockCanvas(Native Method)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.Surface.lockCanvas(Surface.java:243)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.ViewRootImpl.drawSoftware(ViewRootImpl.java:2466)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.ViewRootImpl.draw(ViewRootImpl.java:2440)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2284)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1914)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1024)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:5796)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.Choreographer$CallbackRecord.run(Choreographer.java:761)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.Choreographer.doCallbacks(Choreographer.java:574)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.Choreographer.doFrame(Choreographer.java:544)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:747)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.os.Handler.handleCallback(Handler.java:733)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.os.Handler.dispatchMessage(Handler.java:95)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.os.Looper.loop(Looper.java:136)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at android.app.ActivityThread.main(ActivityThread.java:5102)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at java.lang.reflect.Method.invokeNative(Native Method)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at java.lang.reflect.Method.invoke(Method.java:515)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
11-08 18:28:31.531: E/ViewRootImpl(4749):      at dalvik.system.NativeStart.main(Native Method)

android webview rhomobile

— fnllc
source

Avez-vous trouvé une solution à ce problème?

— Massimo du

Non, mais heureusement avec Android 5+, WebView est maintenant mis à jour via GooglePlay et ce problème disparaît lentement.

— fnllc le

Il s'agit d'un problème de mémoire insuffisante comme indiqué ici:

11-08 18: 28: 31.347: W / Adreno-ES20 (4749):: GL_OUT_OF_MEMORY

android.view.Surfacefait plus de mises à jour que le GPU peut gérer. Je ne suis pas sûr que vous puissiez même essayer d'attraper celui-ci.
Je crois également que sur de nombreux appareils où il n'y a pas de crash, les utilisateurs rencontreront occasionnellement des jambes d'interface utilisateur.

J'ai été confronté à un problème similaire il y a quelques années. Dans mon cas, c'était principalement les jambes, mais je crois que le problème est le même.

Pour le résoudre, j'ai ajouté un compteur pour mesurer la fréquence d'images. J'ai vu que la fréquence d'images est élevée, mais tout d'un coup elle tombe mal, j'ai donc appliqué une logique d'équilibre pour rechercher le FPS le plus élevé qui ne fera pas de jambe.

Commencez avec 60 FPS
Si ses jambes, divisez le FPS par 2
Si ce n'est pas le cas, réglez-le sur la moyenne entre la dernière valeur et le courant.
répétez jusqu'à ce que vous soyez heureux;)

Il s'agit essentiellement d'une recherche binaire du FPS parfait.

Dans votre cas, c'est un peu plus délicat, car vous rencontrez des plantages, vous devrez donc conserver le compteur FPS et faire plus attention à la recherche.

Envoyez les journaux FPS à votre serveur. Une fois que vous aurez suffisamment de données, vous pouvez être plus intelligent avec le point de départ FPS par module d'appareil.

Pour ce qui est de mettre la main sur WebView SurfaceView, je suppose que ce n'est pas non plus anodin, mais nous parlons d'Android 4.4.2, donc il n'y a rien que vous ne puissiez pas faire avec la réflexion :)

— Ilya Gazman
source