(LibGDX) Android-приложение вылетает при создании FrameBuffers

Я получил отчет о сбое из магазина Google Play для одного из моих приложений для Android, созданных с помощью LibGDX.

Huawei MediaPad T3 7 (hwbg2), Android 6.0

java.lang.IllegalStateException:
  at com.badlogic.gdx.graphics.glutils.GLFrameBuffer.build (GLFrameBuffer.java:233)
  at com.badlogic.gdx.graphics.glutils.GLFrameBuffer.<init> (GLFrameBuffer.java:87)
  at com.badlogic.gdx.graphics.glutils.FrameBuffer.<init> (FrameBuffer.java:51)
  at com.badlogic.gdx.graphics.glutils.GLFrameBuffer$FrameBufferBuilder.build (GLFrameBuffer.java:474)
  at com.badlogic.gdx.graphics.glutils.FrameBuffer.createFrameBuffer (FrameBuffer.java:72)
  at com.badlogic.gdx.graphics.glutils.FrameBuffer.createFrameBuffer (FrameBuffer.java:56)
  at MY_PACKAGE.editor.Backup.<init> (Backup.java:21)
  at MY_PACKAGE.editor.EditingImage.<init> (EditingImage.java:277)
  at MY_PACKAGE.screens.EditingScreen.<init> (EditingScreen.java:227)
  at MY_PACKAGE.screens.Screens.<init> (Screens.java:42)
  at MY_PACKAGE.MAIN_CLASS$2.run (MAIN_CLASS.java:121)
  at MY_PACKAGE.screens.SplashScreen.render (SplashScreen.java:93)
  at com.badlogic.gdx.Game.render (Game.java:46)
  at com.badlogic.gdx.backends.android.AndroidGraphics.onDrawFrame (AndroidGraphics.java:495)
  at android.opengl.GLSurfaceView$GLThread.guardedRun (GLSurfaceView.java:1599)
  at android.opengl.GLSurfaceView$GLThread.run (GLSurfaceView.java:1295)

Код в GLFrameBuffer.java:233

if (result == GL20.GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT)
            throw new IllegalStateException("frame buffer couldn't be constructed: incomplete attachment");

EditingImage.java выглядит следующим образом

class EditingImage{

    public static final int pixmapWidth = 1024;

    public EditingImage{
        frameBuffer = FrameBuffer.createFrameBuffer(Pixmap.Format.RGB888,pixmapWidth,pixmapWidth,false);

        ....

        for (int i = 0; i < 50; i++){
          final Backup backup = new Backup(pixmapWidth);
          availableBackups.add(backup);
        }
    }
}

Backup.java выглядит следующим образом

Backup(int width){
    frameBuffer = FrameBuffer.createFrameBuffer(Pixmap.Format.RGB888, width, width, false);
    ....
}

При создании FrameBuffer произошел сбой приложения внутри Backup.java (после того, сколько циклов я не знаю).

Как вы можете видеть, FrameBuffer, созданный в EditingImage, не аварийно завершился и был выполнен до создания экземпляров объектов Backup.

На моем телефоне (Huawei Y6II) работает нормально. Также протестировали на некоторых телефонах Samsung.

Пожалуйста помоги!

Итак, вы создаете 51 кадровый буфер? Вам нужно так много? Возможно, в системе не хватает ресурсов.

Columbo 11.10.2018 10:02

Приложение представляет собой приложение для раскрашивания. Каждый раз, когда пользовательский цвет, я сохраняю резервную копию, скопированную в резервный FrameBuffer, используя основной FrameBuffer, чтобы пользователь мог «отменить» и «повторить». Поскольку существует 50 резервных буферов кадров, пользователь может отменить 50 раз.

Buntu Linux 11.10.2018 10:49

@Columbo. Если я уменьшу количество резервных копий до 20, тогда все будет нормально? У меня нет устройства, на котором происходит сбой приложения, чтобы проверить это.

Buntu Linux 11.10.2018 10:52

Не уверен - я полагаю, что у него есть хорошие шансы сработать, если вы уменьшите до 20. Возможно, вам следует перехватить исключение и использовать его, чтобы ограничить количество доступных буферов отмены. Альтернативой является попытка переработать код так, чтобы вместо каждой резервной копии, являющейся фреймбуфером, они были просто текстурами или даже изображениями, сохраненными во временной папке вашего приложения. Я вообще не знаком с libgdx, поэтому не могу дать подробных указаний о том, как этого добиться.

Columbo 11.10.2018 11:48

Проверьте использование памяти для настольной версии. Т.е. в Windows, Mac или где бы то ни было, где бы вы ни занимались разработкой, запустите свое приложение, откройте диспетчер задач и проверьте, сколько памяти выделяет ваше приложение. Он постоянно растет (у вас есть утечка памяти) или на постоянном уровне (ожидаемое поведение).

MilanG 17.10.2018 11:58
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
0
5
146
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Через 1 год 11 месяцев я обнаружил проблему.

По документации:

https://libgdx.badlogicgames.com/ci/nightlies/docs/api/com/badlogic/gdx/graphics/glutils/FrameBuffer.html

В нем говорится, что формат, который передается в качестве параметра в конструкторе, должен быть RGB565 или RGBA4444 или RGB5_A1

format - the format of the color buffer; according to the OpenGL ES 2.0 spec, only RGB565, RGBA4444 and RGB5_A1 are color-renderable

Где, как в моем случае, я использовал RGB888

Другие вопросы по теме