Android renderer что это

Полный список

— создаем простейший пример с OpenGL

Продолжаем тему графики, и переходим на следующий уровень, который называется OpenGL ES. Расшифровывается это как OpenGL for Embedded Systems, т.е. OpenGL для встраиваемых систем (android-девайсы в нашем случае).

Пару лет назад я читал книгу по этой теме, делал из нее примеры и, в целом, без особых проблем понял, все что там было написано. Но та книжка была по OpenGL ES версии 1.0. Cейчас эта версия уже устарела и используются версии 2.0, 3.0 и 3.1. Эти версии по API существенно отличаются от 1.0 и несовместимы с ней. Поэтому мне самому придется изучать тему почти заново.

Первый урок будет похож на Урок 141. Мы выполним минимальный набор действий, чтобы заполнить экран каким-либо цветом, но в этот раз сделаем это с помощью OpenGL. Кстати, сразу хочу предупредить, что OpenGL это не обязательно 3D. Сначала мы немного порисуем 2D, а потом добавим объем.

Ну и как обычно, поначалу, скорее всего, мало что будет понятно, но по мере погружения в тему общая картина будет проясняться.

Приступим к созданию нашего первого минимального примера. Обсудим его ключевые элементы.

1) Изображение надо на чем-то показывать. Для этого мы будем использовать компонент GLSurfaceView (далее — surface).

2) Изображение кто-то должен создавать, т.е. принимать от нас инструкции, что и как рисовать. Этим будет заниматься Renderer (далее — рендер).

3) Ну и нужна будет проверка, что девайс поддерживает OpenGL 2.0, иначе ничего не будет работать.

Начнем с создания класса рендера. Объект этого рендер-класса мы потом будем передавать в surface, которое в процессе своей работы будет вызывать методы рендера.

Рендер имеет три метода:

onSurfaceCreated — вызывается при создании/пересоздании surface. Т.е. метод будет вызываться при запуске приложения или, например, в уже запущенном приложении при выходе девайса из сна. Здесь будет выполняться установка OpenGL параметров и инициализация графических объектов.

onSurfaceChanged — вызывается при изменении размера surface. Самый распространенный пример — смена ориентации экрана.

onDrawFrame — вызывается, когда surface готово отобразить очередной кадр. В этом методе мы и будем создавать изображение.

Создаем класс OpenGLRenderer, который реализует интерфейс Renderer:

import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.opengles.GL10;

import static android.opengl.GLES20.GL_COLOR_BUFFER_BIT;
import static android.opengl.GLES20.glClear;
import static android.opengl.GLES20.glClearColor;
import static android.opengl.GLES20.glViewport;

public class OpenGLRenderer implements Renderer <

@Override
public void onDrawFrame ( GL10 arg0 ) <
glClear ( GL_COLOR_BUFFER_BIT ) ;

@Override
public void onSurfaceChanged ( GL10 arg0, int width, int height ) <
glViewport ( 0 , 0 , width, height ) ;

@Override
public void onSurfaceCreated ( GL10 arg0, EGLConfig arg1 ) <
glClearColor ( 0f , 1f , 0f , 1f ) ;
>

В onSurfaceCreated мы вызываем метод glClearColor и передаем ему RGBA-компоненты в диапазоне от 0 до 1. Тем самым мы устанавливаем дефолтный цвет, который будет отображаться после полной очистки surface.

А в методе onDrawFrame мы как раз выполняем эту очистку. Метод glClear с параметром GL_COLOR_BUFFER_BIT очистит все цвета на экране, и установит цвет, заданный методом glClearColor.

В методе onSurfaceChanged мы методом glViewPort задаем область surface, которая будет доступна для вывода изображения. Мы указываем левую нижнюю точку — (0,0) и размеры области — (width, height), т.е. изображение будет выведено на все surface.

Рендер готов. Теперь надо в Activity повесить surface и настроить его.

import android.app.Activity;
import android.app.ActivityManager;
import android.content.Context;
import android.content.pm.ConfigurationInfo;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.widget.Toast;

public class MainActivity extends Activity <

private GLSurfaceView glSurfaceView;

@Override
protected void onCreate ( Bundle savedInstanceState ) <
super .onCreate ( savedInstanceState ) ;
if ( !supportES2 ()) <
Toast.makeText ( this, «OpenGl ES 2.0 is not supported» , Toast.LENGTH_LONG ) .show () ;
finish () ;
return ;
>
glSurfaceView = new GLSurfaceView ( this ) ;
glSurfaceView.setEGLContextClientVersion ( 2 ) ;
glSurfaceView.setRenderer ( new OpenGLRenderer ()) ;
setContentView ( glSurfaceView ) ;
>

@Override
protected void onPause () <
super .onPause () ;
glSurfaceView.onPause () ;
>

@Override
protected void onResume () <
super .onResume () ;
glSurfaceView.onResume () ;
>

private boolean supportES2 () <
ActivityManager activityManager =
( ActivityManager ) getSystemService ( Context.ACTIVITY_SERVICE ) ;
ConfigurationInfo configurationInfo = activityManager.getDeviceConfigurationInfo () ;
return ( configurationInfo.reqGlEsVersion >= 0x20000 ) ;
>

В onCreate мы сначала нашим методом supportES2 определяем, что девайс поддерживает OpenGL ES 2.0 и выше. Если нет, то закрываемся.

Если же все ок, то
— создаем GLSurfaceView,
— методом setEGLContextClientVersion говорим ему, что будем использовать OpenGL ES версии 2
— методом setRenderer передаем экземпляр нашего класса OpenGLRenderer. Теперь этот рендер будет отвечать за то, что будет нарисовано на surface
— методом setContentView ставим surface как основное View для Activity

Кроме этого, необходимо привязать surface к lifecycle-методам Activity: onPause и onResume, вызвав в них одноименные surface-методы.

Все готово. Запускаем

Экран заполнен зеленым цветом. Первое простейшее OpenGL-приложение готово. Не Need For Speed конечно, но с чего то ж надо начинать )

Три момента, на которых я хотел бы еще остановиться

1) Почему-то не работает alpha-компонент в методе glClearColor. Т.е. передаете последним параметром хоть 0 хоть 1, прозрачность не добавляется. На этот вопрос у меня пока ответа нет.

2) Координаты viewport, которые мы задаем методом glViewport никак не влияют на результат, и даже если задать область viewport только в половину surface, все равно в зеленый цвет будет закрашена все surface. По этому поводу я вычитал, что это норма. Метод glClear работает на все surface, независимо от размера viewport.

3) По поводу запуска приложений. Обычно пишут, что OpenGL ES не пашет на эмуляторах. Я не проверял на стандартном эмуляторе, но на Genymotion запуcкается без проблем. На крайняк всегда есть реальный девайс, можно тестить на нем.

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме

Источник

Как заставить рендеринг GPU на Android —

когда Рендеринг с помощью графического процессора добрался до Android, это было ненадежно, если не сказать больше. Официальная цель — повысить производительность приложений, но тогда многие графические пользовательские интерфейсы не знали, как работать с рендерингом на GPU. В некоторых случаях это было даже медленнее, чем программный рендеринг.

Со временем, особенно после появления Android 4.0, графический процессор стал более надежным и постепенно стал стандартным для большинства приложений. В настоящее время большинство обновленных приложений имеют встроенный графический рендеринг.

Но прежде чем мы перейдем к тому, как и когда включить эту опцию, давайте разберемся, как она работает.

Что такое рендеринг на GPU?

GPU является Графический процессор. По своей сути он очень похож на ЦП, но вместо выполнения вычислений и выполнения задач, связанных с операционной системой и оборудованием, графический процессор обрабатывает графическую информацию. Другими словами, это помещает материал на экран, чтобы ваши глаза могли видеть.

Хотя процессор прекрасно способен обрабатывать графические инструкции, это отнимет уйму времени на выполнение других важных для системы вещей, что может привести к задержке. Более того, конструкция ЦП делает их совершенно неэффективными при обработке графических данных по сравнению с графическими процессорами, которые запрограммированы на обработку графической информации.

Это где Графический процессор приходит — он отнимает часть графической обработки от процессора, освобождая его для более важных дел. Поскольку графический процессор намного лучше с графическими данными, конечный результат — лучшая производительность как для процессора, так и для графического процессора.

Когда форсировать рендеринг на GPU

Включение этого параметра приведет к разгрузке таких компонентов окна, как текст, кнопки и расчеты 2D-графики, в графический процессор. Это позволит вашему устройству лучше отображать анимацию пользовательского интерфейса и чувствовать себя менее запаздывающим. Хотя вы, безусловно, достигнете более плавного восприятия и лучшей частоты кадров в 2-мерных приложениях, ваше устройство может в итоге использовать больше батареи. Известно, что графические процессоры потребляют больше энергии, чем процессоры, поэтому ожидайте, что время автономной работы уменьшится на 10-15%, если оставить его включенным постоянно.

Принудительное рендеринг с помощью графического процессора определенно имеет смысл на устройствах с более слабым процессором. Если ваше устройство является чем-то меньшим, чем четырехъядерный процессор, я бы рекомендовал вам всегда оставлять его включенным.

Но имейте в виду, что рендеринг с помощью графического процессора эффективен только для двумерных приложений. Большие игры с использованием 3D-графики могут иметь худшую частоту кадров при Force GPU Rendering включен. Хорошо то, что большинство версий Android не будут мешать 3D-приложениям и будут вызывать рендеринг с помощью графического процессора только в тех приложениях, которые не используют его по умолчанию.

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

Суть в том, что вам решать, хотите ли вы обменять срок службы батареи на повышенную текучесть и некоторые дополнительные частоты кадров. Имея это в виду, вот как включить Force GPU Rendering.

Источник

GPU-ускорение на Android — что это и нужно ли включать?

Смартфоны на Android с каждым годом работают быстрее: производители устанавливают новые процессоры и GPU, увеличивают объем оперативной памяти. Сегодня мобильное устройство может заменить ноутбук — мощности гаджета хватит, чтобы полноценно пользоваться интернетом и даже обрабатывать видео.

В операционной системе Android есть дополнительные функции, которые помогут увеличить скорость работы смартфона. Один из таких инструментов — GPU-ускорение.

Нужно ли включать GPU-ускорение на телефоне?

GPU — встроенный графический процессор. Задача GPU-ускорения — принудительный перенос процесса рендеринга изображения с процессора смартфона на GPU. Таким образом повышается общая производительность мобильного устройства — после активации этого режима увеличивается скорость обработки информации в производительных играх и приложениях (утилиты для обработки и рендеринга видеороликов, фотографий, графические приложения).

Если в некоторых играх или программах снижается производительность, активируйте GPU-ускорение. Это не навредит смартфону, единственное, что может произойти — некоторые утилиты перестанут запускаться.

Для включения GPU-ускорения откройте настройки гаджета. После этого перейдите в раздел «Для разработчиков» — вот подробная инструкция по его открытию.

В меню разработчиков находится подраздел «Аппаратное ускорение визуализации». Активируйте функцию «GPU-ускорение». Теперь гаджет будет использовать максимальное количество системных ресурсов, чтобы обеспечить высокую производительность в приложениях.

Источник

Русские Блоги

Анализ модуля аппаратного ускорения Android HWUI

Что такое аппаратное ускорение (Что)

Рисование пользовательского интерфейса традиционного программного обеспечения выполняется центральным процессором, а аппаратное ускорение заключается в передаче задачи рисования на графический процессор для выполнения. Модули, отвечающие за аппаратное ускорение в системе Android, в основном HWUI ,Как показано ниже:

Почему аппаратное ускорение (почему)

Базовая реализация аппаратного ускорения Android HWUI основана на OpenGL ES Интерфейс отправляет инструкции графическому процессору для завершения рисования. Преимущества аппаратного ускорения:

• В среде с высоким разрешением экрана (особенно для телевизоров 4K HD) частота кадров при отрисовке пользовательского интерфейса графического процессора выше, чем у ЦП, и в то же время это может снизить нагрузку на ЦП. Если для программного рисования используется только ЦП, рентабельность слишком мала.
• Графический процессор больше подходит для выполнения трудоемких задач, таких как растеризация и преобразование анимации. По сравнению с использованием центрального процессора для выполнения этих задач на мобильных устройствах, графический процессор позволяет сэкономить электроэнергию и повысить удобство работы пользователей.
• Современные мобильные графические процессоры поддерживают программируемые конвейеры и могут эффективно создавать некоторые специальные эффекты (вдох, градиент, размытие, тень) интерфейса приложения.

Реализация аппаратного ускорения (Как)

Реализованный исходный код находится в каталогеandroid/platform/framework/base/libs/hwui

Независимый поток рендеринга

На Android 5ThreadedRendererПоявление снижает нагрузку на основной поток и может быстрее реагировать на действия пользователя.

Ниже приведен аварийный стек аппаратного ускорения Android 5. По этой взаимосвязи вызовов мы можем приблизительно узнать поток вызовов от View к RenderNode.

Посмотрите еще раз на функцию nDrawRenderNode: в методе drawRenderNode объекта DisplayListRenderer DrawOp объекта RendeNode записывается в DisplayListData.

На следующем рисунке показан DrawOp, записанный в DisplayList:

Список отображения и пакетная визуализация

На следующем рисунке показан процесс выполнения OpenGL Renderer Android 5.1 списка отображения:

Класс OpenGLRenderer в основном отвечает за выполнение API GL и обновление настроек состояния рендеринга.

Как показано в приведенном выше коде, нарисованная партия Текст, изображения, геометрические фигуры Эффект от рисования партиями показан на рисунке ниже.

Так как же HWUI объединяет каждый DrawOp?

После Android 4.4 модуль HWUI удаляет нарисованную область через список отложенного отображения для завершения пакетной обработки и объединения DrawOp.

Давайте посмотрим на метод canMergeWith класса MergingDrawBatch в DeferredDisplayList.cpp:

Объединение DrawOp зависит от того, согласовано ли состояние соответствующего конвейера рендеринга DrawOp.Как правило, DrawOp одного и того же состояния объединяется, чтобы уменьшить эффект переключения состояния рендеринга.

В модуле HWUI реализация пакетного слияния DrawOp в основном DeferredDisplayList :: addDrawOp метод , Как показано в следующем фрагменте:

DisplayList записывает операции рисования и состояние, а основной поток отправляет их в средство визуализации OpenGL, которое выполняет последний вызов DrawCall.

Преимущества пакетного рендеринга и слияния DrawOp очевидны. Это значительно снижает накладные расходы на переключение состояния рендеринга OpenGL (из-за сложности реализации драйвера OpenGL ES каждый вызов привязки GL и переключение состояния GL вызовут операции проверки состояния GL и синхронизации) 。

Создать набор текстур

AssetAtlasService выполняет специальное управление загрузкой ресурсов. Чтобы сократить время загрузки ресурсов изображений в GPU, он объединяет и упаковывает все ресурсы (алгоритм Атлас реализован вgraphics/java/android/graphics/Atlas.javaClass) загрузить как одну текстуру, пройти UvMapper переназначает координаты текстуры на интервал [0, 1] , Чтобы пользовательский интерфейс по-прежнему можно было рисовать правильно.

Поскольку процесс приложения является ответвлением процесса Zygonte, ресурсы текстуры, загруженные AssetAtlasService, могут использоваться совместно с приложением.

Использование ATLAS снижает потребление памяти графического процессора и накладные расходы на вызовы привязки текстурных модулей (Texture Unit) (Resource Binding).

Рисунок шрифта

Рендеринг текста также является головной болью. Рендеринг текста в приложении не так прост, как в играх. Обычно, когда игра выпускается, фиксированный текст может быть заранее преобразован в единую текстуру, а координаты текстуры могут быть напрямую сопоставлены при рендеринге текста. . Нижний слой Android кэширует данные текстуры текстовых глифов. Android использует Skia и стороннюю библиотеку шрифтов с открытым исходным кодом (FreeType) для растеризации шрифтов.

Если устройство поддерживает OpenGL ES 3.0, Android будет использовать Привязка PixelBufferObject Завершите асинхронную загрузку текстур шрифтов. Преимущество этого заключается в том, что данные текстуры загружаются в графический процессор более эффективно с помощью метода сопоставления (glMapBuffer). Конкретная реализация:libs/hwui/PixelBuffer.cpp:

PBO сокращает время ожидания загрузки ресурсов текстур шрифтов и улучшает работу интерфейса.

Сценарий применения

В нашей обычной разработке спроса мы столкнемся с некоторыми сценариями, которые могут быть выполнены с помощью аппаратного ускорения. Например, при выполнении анимации с альфа-градиентом в сложном макете мы можем напрямую установить для родительского макета LayerType значение LAYER_TYPE_HARDWARE 。

Когда LayerType View установлен на HARDWARE, View будет привязан к OpenGL ES FrameBufferObject. Если View должен быть анимирован (Alpha, Rotation и т. Д.), FrameBufferObject будет отрисован в текстуру (RTT, Render To Текстура), а затем отрендерить анимацию, но здесь следует отметить, что использование памяти увеличится.

Улучшения аппаратного ускорения

Точки оптимизации могут быть расширены с точки зрения API и аппаратных характеристик GPU:

• После упоминания iOS 8 был представлен Metal, который изначально поддерживает многопоточный рендеринг графического процессора. Android не может сильно снизить производительность графического процессора из-за различий в драйверах GL и реализациях поставщиков графических процессоров, но в следующем поколении графического API (VulkanПосле популяризации остается еще много возможностей для оптимизации, и беглость пользовательского интерфейса можно улучшить.
• Большинство графических процессоров мобильных устройств основаны на рендеринге на основе тайлов, и алгоритм пакетного рендеринга можно рассматривать в пакетном режиме на основе тайлов.

На SIGGRAPH этого годаGoogle публично поддержал Vulkan, Он станет основным графическим интерфейсом на устройствах Android следующего поколения.

Источник