делает ли onDraw в контейнере SurfaceView видео недействительным?

У меня есть просмотр видео. Это представление содержится внутри пользовательского FrameLayout под названием VideoStructure, где я также могу поместить логотип канала или что-то подобное. введите здесь описание изображенияВ нормальных условиях видео ускоряется аппаратно, поэтому вид (я полагаю) действительно прозрачная «черная дыра», в то время как видео декодируется и обрабатывается соответствующим оборудованием.

Мой вопрос: если я переопределю draw() в контейнере просмотра видео (VideoStructure расширяет FrameLayout на изображении), чтобы нарисовать что-то (например, круг на изображении) НАД видео - я переопределяю draw(), а не onDraw()- не сломает ли это аппаратное ускорение? Могу ли я ожидать большой производительности для этого?


android hardware-acceleration optimization android-videoview surfaceview
person rupps    schedule 17.04.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Это не должно влиять на производительность.

SurfaceViews состоит из двух частей: части «представления» и части «поверхности». Часть «вид» представляет собой прозрачное отверстие, которое соответствует другим видам, часть «поверхность» представляет собой полностью независимый слой, который скомпонован системой со слоем вида. Видео отправляется в "поверхностную" часть.

Если вы переопределите рендеринг «представления» SurfaceView, вы получите холст с аппаратным ускорением для представления, которое обычно полностью прозрачно (поэтому, если вы стираете его, вам лучше использовать нулевую альфу и правильный режим передачи).

Если вы попытаетесь выполнить рендеринг на «поверхностной» части, получив Canvas от lockCanvas(), вы либо потерпите неудачу (поскольку видео фактически заблокировано), либо преуспеете и предотвратите запись видео на него.

Системному компоновщику придется смешивать слои «представление» и «поверхность» независимо от того, что появляется в слое «представления», поэтому создание непрозрачности еще нескольких пикселей не окажет заметного влияния.

Обновление: дополнительные сведения см. в документе по графической архитектуре. Поверхности и композиция.

person fadden    schedule 17.04.2014
comment
ооо, какое точное объяснение, как раз то, что я хотел знать! - person rupps; 17.04.2014
comment
@fadden - я знаю, что это старый ответ, но он появляется при поиске и очень подробен, как примечания rupps, поэтому быстро ответьте на вопрос: как мы интерпретируем метод onDraw - вызывается ли он, когда часть «представление» или часть «поверхностная» часть вашего ответа обращена к (или к тому и другому)? Я предполагаю, что может случиться так, что системный компоновщик должен смешивать представление и видео с каждым записанным видеокадром, и именно поэтому, как обсуждалось в другом месте, вы можете рассчитать частоту кадров видео, взглянув на представление onDraw? - person Mick; 09.09.2015
comment
Платформа приложения вызывает onDraw(), когда представление становится недействительным. Это не называется обновлениями видео. Имейте в виду, что пользовательский интерфейс просмотра и видео рендерятся в отдельные наборы графических буферов, оба из которых передаются системному компоновщику (первый — приложением, второй — видеокодеком в процессе медиасервера). Вы не можете рассчитать частоту кадров видео из onDraw(), если только вы не декодируете видео в программном обеспечении и не выдаете недействительный запрос для каждого кадра. - person fadden; 09.09.2015
comment
Хорошее объяснение, особенно примечание об отдельных графических буферах (мне придется проработать документ, на который вы ссылались выше...). - person Mick; 09.09.2015