Pull to refresh

Comments 21

Хорошая статья. В наши дни фронт-енд разработчики начинают думать про оптимизацию и аппаратное ускорение лишь тогда, когда страница начинает заметно подлагивать (и появляются недовольные пользователи вследствие негативного UX) через десятки/сотни программных анимаций/эффектов/переходов. Я считаю, что возможности CSS3 (и использование много чего из CSS2) должны спасти мир от «раздувания» ПО в вебе, которое сейчас на критично высоком уровне. Иногда пара строк в CSS работает в разы лучше и проще, чем пара десятков оних в JS.
Как раз дебажил приложение для Firefox OS на слабом смартфоне, там как раз left/top заменил на 3d трансформации, и стало намного лучше.
Вот бы на пару недель раньше мне эту статью)
Путем сложных математических вычислений приходим к выводу, что каждый фрейм у нас создается раз в 16.6 миллисекунд.

Где же тег sarcasm? )
Спасибо за статью и отдельный комплимент презентации. Хочется спросить про один странный баг со шрифтами, доставивший массу неудобств полгода назад. На Mac OS в Safari в некоторых местах начинал загадочным образом мигать текст — шрифт то становился тонким, то толстым, примерно каждую секунду так переключался. В Chrome тоже было, но гораздо менее заметно, а вот в Firefox нормально. Долго и безрезультатно бился с этим миганием, так и не смог исправить. Помимо своих проектов встречал на множестве других сайтов, даже у гугла. Так понимаю это и есть та проблема с блюром? Правильно ли я понимаю, что для исправления проблемы, надо было выделять блоки с текстом в отдельный композитный слой (z-index'ом), поскольку анимация у меня происходила только в баннере, а текст просто висел статичным, без всяких анимаций, но тем не менее мигал? К сожалению не могу найти тот злосчастный баннер, из-за которого мигал текст в некоторых блоках на сайте, чтобы испробовать советы из доклада.
Скорее всего вы видели что-то типа этого: files.chikuyonok.ru/anim-demo/

И в большинстве случаев причина — неправильная композиция слоёв. В данном примере слой .anim переносится на GPU для ускорения анимации. То есть для этого слоя создаётся отдельная 3D-плоскость со своей текстурой, которая и компонуется с остальной страницей (которая, к слову, тоже является своего рода 3D-плоскостью). Однако слой .text по z-index находится выше слоя .anim, и браузеру ничего другого не остаётся как вынести слой .text также на отдельную плоскость в GPU, чтобы на экране вы увидели именно то, что задумали.

Соответственно, этот вынос слоя с текстом на GPU (вернее, особенность Safari отрисовки текста на прозначном фоне для GPU-слоя) и даёт тот самый артефакт, Обратите внимание, что этот артефакт появляется строго в начале и в конце анимации, то есть когда меняется 3D-композиция.

Решений этой проблемы несколько:

  1. Перенести слой .text по z-index ниже слоя .anim, если дизайн это позволяет. В этом случае не будет происходить неявный вынос слоёв в 3D. Это самое правильное и оптимальное решение.
  2. Указать слою .text непрозрачный фон, например, белый. Так вы замаскируете артефакт, но не избавитесь от проблемы неявного выноса. А это именно проблема, так как вынос на GPU – это всегда отдельный repaint и отдельная память.
  3. Явно вынести слой .text на GPU, хоть тем же translateZ(0). Так вы сделаете артефакт постоянным, но он хотя бы не будет «моргать». И вы также не избавитесь от проблемы.


Вообще, прежде чем выносить что-то на GPU нужно хорошо представлять себе, что это такое и как именно это работает в недрах системы. Не стоит полагаться, что добавление «волшебного» translateZ(0) также «волшебно» ускорит страницу. Да, анимация будет быстрее, однако при неправильной композиции вы рискуете получить кучу проблем на скролле страницы или на банальном ховере на ссылках.
Спасибо большое за подробный ответ. Одной загадкой в жизни меньше стало, это радует.

Да, именно эта проблема. В Chrome уже не мигает, исправили, вестимо, вместе с новым рендером шрифтов, по крайней мере я не замечаю, а вот в Safari проблема так и осталась, печально.

Правильно ли я понимаю, что есть еще и четвертый вариант — убрать пересечние блока с текстом и блока с анимацией? Видимо не правильно, т.к. попробовал в примере сдвинуть кубик сильно вниз (top: 300px), но проблема осталась. Это значит слои не ограничиваются блоком, а занимают всю страницу?
четвертый вариант — убрать пересечние блока с текстом и блока с анимацией?

Нет, пересечения тут ни при чем, вынос происходит именно по z-стэку. Потому что браузер не может знать заранее, будут ли блоки пересекаться, если вы, например, анимируете их через JS.
Эффект наблюдается только при включенном субпиксельном сглаживании шрифтов. При рендеринге шрифта в отдельный слой субпиксельное сглаживание выключается, потому что оно не возможно, если не известен цвет фона.
На самом деле, приведённая схема работы браузеров (DOM Tree → Render Tree → …) справделива для webkit, gecko и blink; в Internet Explorer, а также в Servo, схема другая.
UFO just landed and posted this here
Нигде, насколько я знаю. Я об этом знаю постольку, поскольку мы обсуждали API для Render Tree, и представитель Мозиллы заметил, что не все браузеры имеют схожий воркфлоу.
UFO just landed and posted this here
Я не знаю деталей. Просто говорю, что попытки стандартизировать API для Render Tree и Box Tree проваливаются именно по этой причине.
… я увидел у слайда CSS свойство background-size: cover. Это свойство растягивает картинку на всю площадь блока… Ресайз картинки — это очень дорогостоящая операция, поэтому я отключил это CSS свойство и все стало совсем хорошо.


Ресайз картинки — дорогая операция, но делается один раз на repaint. Поэтому проблема с производительностью не в других размерах у картинки, а в постоянной перерисовке блока. А это, скорее всего, из-за неправильной композиции.
А вы можете написать статью о том, как записываете лекции, какую технику и технологии используете?
Сам работаю в ВУЗе, но у нас запись преподавателей проходит по-проще.
Интересный вопрос, не встречали ли вы проблем при подключении translateZ(0) на сайте? у кого проблемы с драйверами на видюху, у них при заходе на страницу просто комп вырубается, у нас так много пользователей на линукс стали жаловаться на это :)
На самом деле иметь отдельные слои и уж отдельный rendering process совершенно не обязательно при наличии современных механизмов 2D rendering. Мой Sciter например с Direct2D backend рисует напрямую вызывая D2D примитивы как они есть. И что-то мне говорит что IE поступает также.

Промежуточные bitmap buffers (a.k.a. layers) нужны при определенных анимациях, это да. Но это редкое исключение.
Из инструментов для мониторинга рендера вы используете только стандартные Chrom DevTools или какие-то плагины еще?
Все верно.
Chrome дает мощнейшие инструменты для мониторинга процесса отрисовки и композитинга. Сюда же я отношу инструмент Tracing (chrome://tracing) в Chrome Canary. Пример пошаговой растеризации и отрисовки страницы и 3D модель слоев из презентации были сделаны с помощью этого инструмента.
По поводу Chrome DevTools есть хорошие видео от Paul Irish. На русском языке есть интересный доклад (свежак) с последнего FrontTalks в Екатеринбурге (19 сентября) от Романа Сальникова.
Упоминая последний FrontTalks не могу не оставить ссылку на изумительный доклад Вадима Макишвили из 2 слайдов.
36, да. Я видел его в трансляции. У самого такие же проблемы, частично он дал ответы.
Sign up to leave a comment.