Почему браузеры недостаточно умны, чтобы аппаратное ускорение без трюков?

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

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

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


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

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

2 ответов


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

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

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

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

EDIT: я также должен добавить, что в самых последних версиях Android Google добавил аппаратное ускорение в Skia, которое обрабатывает почти весь 2D-рендеринг в ОС. Не многие устройства в дикой природе имеют это еще, но это означает, что производительность улучшится для всего на Android в ближайшее время. Тем не менее, я не знаю, работает ли их реализация Skia так же легко с OpenGL, как нам может понравиться. Композиция все еще может потребовать некоторых дополнительных копий, пока они не разберутся с этим.


для получения дополнительной информации о подходе webkit, Ария Hidayat (webkit reviewer) написал довольно хороший вводный пост в блоге об аппаратном ускорении и webkit для нашего блога. Наслаждаться.

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