Почему браузеры не настолько умны, чтобы аппаратно ускоряться без хитростей? - PullRequest
14 голосов
/ 30 января 2012

В наши дни существуют тонны веб-страниц, которые рекомендуют вам добавить эти правила к своему контенту, чтобы сделать его аппаратно ускоренным:

transform: translate3d(0,0,0);
-webkit-transform: translate3d(0,0,0);

Это всегда казалось мне смешным. Зачем браузеру нужна моя помощь, чтобы принять решение об аппаратном ускорении? Это будет быстрее, верно? Так почему бы просто не сделать это? Зачем ждать, чтобы я «обманул» браузер?


Еще один способ задать этот вопрос: почему не все таблицы стилей baseline / reset содержат строки

* {
    transform: translate3d(0,0,0);
    -webkit-transform: translate3d(0,0,0);
}

Ответы [ 2 ]

27 голосов
/ 30 января 2012

Это не так много, что браузеры не могут быть или недостаточно умны, чтобы использовать аппаратное ускорение.Вместо этого то, на что вы ссылаетесь, действительно применимо только к WebKit, особенно к мобильным версиям WebKit.Firefox и IE оба аппаратно ускоряют все, и они автоматически разделяют страницу на «слои», которые скомпонованы на GPU.Вот почему они обычно обгоняют Chrome при тестировании скорости рендеринга.WebKit, с другой стороны, никогда не был адаптирован для ускорения слоев.

Поскольку Firefox и IE могут использовать преимущества рендеринга Direct2D на платформах Windows (где каждая операция рисования выполняется с аппаратным ускорением)По сути, это было требование, чтобы они также могли выполнять композитинг с аппаратным ускорением.Если бы они только ускорили операции рисования, а не композитинга, они потеряли бы большую часть преимущества в скорости благодаря использованию Direct2D, потому что это потребовало бы копирования между GPU и системной памятью, что является медленным.С другой стороны, все бэкэнды рендеринга WebKit, о которых я знаю, выполняют рендеринг полностью в программном обеспечении и подвергаются штрафу за копирование в GPU при их компоновке (если используется компоновка GPU).Таким образом, это в конечном итоге компромисс.Если слой, который вы создаете, не требует много времени для рендеринга на CPU, не всегда имеет смысл вообще выполнять копирование и компоновку на GPU.

Из-за этого, а также длякрайне ограниченный характер мобильных графических процессоров, ни один из браузеров WebKit еще не начал выполнять автоматическое аппаратное ускорение, кроме случаев, когда это абсолютно необходимо (например, при настройке 3D-преобразования).Если бы вы хотели услышать мое мнение, я бы также добавил, что я думаю, что лень со стороны разработчиков и поддерживающих компаний WebKit также является здесь одним из факторов.Использование графического процессора является основным источником ошибок, поэтому им проще просто не использовать его, а не исправлять проблемы.

Кстати, Firefox для Android может все время выполнять компоновку GPU, хотя вывозможно, потребуется включить его в about: config;Я не знаю, включен ли он по умолчанию.Для ПК я бы порекомендовал использовать Firefox или IE для очень быстрого рендеринга.

РЕДАКТИРОВАТЬ: я также должен добавить, что в самых последних версиях Android Google добавил аппаратное ускорение в Skia, который обрабатывает почти все 2Dрендеринг на ОС.Пока не многие устройства в дикой природе имеют это, но это означает, что производительность будет улучшаться для всего на Android в ближайшем будущем.Тем не менее, я не знаю, работает ли их реализация Skia с OpenGL так легко, как нам хотелось бы.Компоновка все еще может привести к дополнительным копиям, пока они не справятся с этим.

1 голос
/ 30 января 2012

Для получения дополнительной информации о подходе webkit Ария Хидаят (обозреватель webkit) написала довольно хорошее вступительное сообщение в блоге по аппаратному ускорению и webkit для нашего блога. Наслаждайтесь.

[Суть в том, что ускорение HW может поглотить много памяти, поэтому будьте осторожны.]

...