С Open GL никогда дела не имел, задам общий вопрос:
Нужно отрисовать 20 плоских объектов (квадратов), на каждом из объектов 5 елементов (текстур, 2 из которых большие 1024х1024, уменьшать не вариант, нужна четкость). Можно считать и по другому, 20 объектов, по 5 квадратов по 1 текстуре, я не знаю как будет быстрее. Текстуры, как я уже сказал, большие и ARGB_8888, GL_BLEND включен, получаются в рантайме при запуске приложения, сжатие применить нет возможности (или есть?).
Допустим тестовая платформа это Galaxy S3, ничего слабее не учитываем.
Может ли GLES20 отрисовать все это с 60 fps?
P.S. Реализация на View'хах не удовлетворяет плавности и поеданию памяти. Пытаюсь реализовать на GLES но оно сейчас безбожно тормозит, поэтому и ищу где у меня руки недостаточно прямые.
используйте PVRTC сжатие и выставите правильно фильтры (GL_TEXTURE_MAG_FILTER и GL_TEXTURE_MIN_FILTER). И если поддерживается GL_TEXTURE_MAX_ANISOTROPY_EXT
у меня 60+ текстур от 1к, только платформа другая. OpenGL ES 2.0
Это не игра или графическое приложение, а UI, хочется и плавно и четко. Фильтры серьезной разницы в производительности не дают, с анизотропией попробую поигратся. У данного чипа GPU Mali, PVRTC сжатие не подойдет. Сжатие может серьезно поднять скорость рендеринга?
В профайлере рендениг занимает не более 3мс, и около 60мс — eglSwapBuffers, в GPU профайлере время на рендеринг аналогичное (при отрисовке одного квадрата, когда не тормозит, eglSwapBuffers занимает 13мс, тоесть время на синхронизацию для 60фпс (1000/60=16.6мс)). Это нормально?
Без блендинга за счет отсекания поверхностей все рисуется быстро… Но с…
А ETC1 сжатие не поддерживает альфа канал, конечно можно разделить текстуры но по моим наблюдениям как-раз вызовы texture2D и отъедают больше всего времени…
>>Сжатие может серьезно поднять скорость рендеринга?
не особо, это больше на то чтоб меньше памяти хавало. Какой OpenGL используется сейчас? Может в шейдере дело или там ничего серьезного?
GLES 2.0. С памятью проблем нет, у меня всего будет максимум 22 больших текстуры, и 60 маленьких (до 16 000 квадратных пикселей :) ).
В шейдерах ничего сложного, только вызовы texture2D и mix(). Для эксперимента оставлял только одну текстуру на квадрат — при 20 квадратах уже фпс падает но не сильно. Все возможные биндинги и передачи параметров вынес в onSurfaceChanged() Примерная последовательность действий (сейчас доступа к коду нет):
Сейчас только одна из пяти текстур меняется от квадрата к квадрату, остальные забиндены в onSurfaceChanged и не меняются.
Микс этот — мое видение наложения текстур нескольких текстур на квадрат (сделал себе более правильную функцию но в тестах не использую пока не добьюсь вменяемой производительности). Опять же, без микса (1 текстура на квадрат) тормоза проявяются на 20 квадратах.
GPU профайлер на ошибки не ругался, но проверки повставляю.
Сжатие только замедляет отрисовку, что в принципе логично.
Попробуйте покрутить точность в шейдере: precision mediump float и всё такое. Вдруг поможет. Могут и артефакты от этого появиться, надо смотреть.
Если 4 текстуры из 5 меняются редко, то стоит попробовать предварительно отрисовывать их в одну текстуру — типа кэширование.
У меня опыт только с iOS — вот там fill rate весьма ограничен, и это быстро приводит к просадке fps при рисовании на экране больших текстур. Надо думать об уменьшении количества «перерисовок» пикселей.