• Анимации на GPU: делаем это правильно
    0

    Тут больше важно не количество слоёв, а их размер. Но и увеличивать количество слоёв лишний раз не стоит. Например, браузер может по своей внутренней логике прекратить предварительный перенос на композитный слой элементов с will-change, если слоёв станет слишком много. Chrome может по той же причине может включить Layer Squashing, с которым мне приходилось бороться, так как оптимизированный вариант занимал слишком много памяти. Каких-то конкретных цифр назвать не могу.

  • Анимации на GPU: делаем это правильно
    0

    Можно сделать без лишних классов и @keyframe-секций ;)

  • Анимации на GPU: делаем это правильно
    +2

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

  • Анимации на GPU: делаем это правильно
    +1

    Каждый слой — это отдельное изображение, размер которого и отображается. Вы можете написать предложения с улучшениями разработчикам Chrome DevTools ;)

  • Анимации на GPU: делаем это правильно
    0

    Судя по скриншотам, вы в обоих случаях смотрите размеры рутового слоя. Раскройте слева секцию document и найдите там нужный слой

  • Анимации на GPU: делаем это правильно
    +1

    Для картинки без разницы, что там нарисовано: тень или что-то ещё. Это просто набор пикселей.


    Можете пример показать, где при изменении размера блока не меняется расход памяти?

  • Анимации на GPU: делаем это правильно
    +1

    Объём занятых ресурсов отображается в панели Layers, по ней и мониторю. В Хроме ещё есть chrome://tracing/, но там тяжелее мониторить, но вроде как более достоверная информация

  • Анимации на GPU: делаем это правильно
    +3

    Честно признаюсь: так глубоко не влезал. Но из найденной информации вроде как возможность компрессии текстур зависит от поддерживаемых OpenGL расширений и эта поддержка зависит от конкретного вендора GPU. Да и и при общении с разработчиками Chrome DevTools пару лет назад они обмолвились, что вроде как слои без компрессии хранятся.

  • Низкий FPS при прокрутке страницы. Решение проблемы background-attachment: fixed
    +3
    Свойство will-change предписывает браузеру отображать элемент, независимо от окружающих его других элементов.

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


    В целом у этого решения (принудительный вынос всего подряд на отдельный композитный слой) есть очень много побочных эффектов: как минимум увеличенное потребление памяти, как максимум — repaint всего слоя на, казалось бы, банальных вещах вроде изменения цвета ссылки внутри слоя по ховеру. Так что следует пользоваться этим аккуратно и следить в DevTools/Web Inspector за аномальным перерисовками.

  • Оптимизация рендеринга веб-страницы
    +3
    Вроде через chrome://tracing/ это можно отловить, хотя не так удобно, как через Timeline
  • Оптимизация рендеринга веб-страницы
    +3
    Да, есть такое свойство. С помощью которого вы всего лишь говорите браузеру «я планирую менять вот такие свойства, оптимизируй это как-нибудь». А как браузер это оптимизирует — вынесет отдельным слоем на GPU, склеит с другими блоками и вынесет отдельным слоем или вообще оставит на основном холсте — вы не знаете. Вы не можете с помощью этого свойства сказать «сразу вынеси этот слой на GPU, потому что потом я буду анимировать кучу блоков и мне не нужен лишний repaint перед стартом анимации; я даю отчёт всем своим действиям и принимаю на себя все возможные риски». Я очень долго на последнем визульано-сложном проекте искал возможность сделать именно так, и никакой will-change тут не помогал. Я пытался именно обойти браузерную оптимизацию и контролировать весь процесс самостоятельно для достижения нужного соотношения производительности и расхода памяти.
  • Оптимизация рендеринга веб-страницы
    +10
    У данного подхода, тем не менее, есть отрицательная сторона.

    Их гораздо больше :) И если их не учитывать — получим обратный эффект: сильное снижение производительности.

    1. Отдельный GPU-слой почти всегда занимает отдельную память, которую можно посчитать (в байтах) по довольно приблизительной формуле width × height × 4. То есть чем больше слоёв (и чем больше физические размеры слоя), тем больше расход памяти. Неумелым использованием слоёв можно очень быстро вырубить браузер на мобилках.
    2. В Webkit-браузерах (десктоп и мобильные) слой перерисовывается целиком. Это значит, что если где-то внутри слоя поменяется хотя бы один пиксель, браузер сделает repaint всего слоя, а также потратит время на перенос его в GPU. Хотя Blink и научился оптимизировать такие вещи, за этим всё равно нужно следить с помощью описанных в статье инструментов.
    3. Если GPU-слой по z-index будет ниже, то и этот слой тоже будет вынесен на GPU. Со всеми последствиям, описанными выше и с возможными артефактами отрисовки.


    Вообще стоит понимать, что GPU-слои (или compositing, как это называется в Blink) — это один большой хак, который сами разработчики браузеров пытаются от нас скрыть и заставить браузер работать так, будто никаких GPU и не-GPU слоёв нет. Поэтому нет никакого «официального» описания как этим правильно пользоваться. Более того, поведение браузеров постоянно меняется: например, Blink далеко не всегда принудительно вынесет слой на GPU даже если ему указать transform: translateZ(0), так он пытается оптимизировать работу с памятью и железом. Иногда это к лучшему, а иногда приходится искать варианты обхода этой оптимизации, чтобы браузер не делал лишний repaint перед анимацией.

    Поэтому когда собираетесь выносить что-то на GPU, нужно чётко представлять себе все возможные последствия и уметь правильно пользоваться инструментами для отладки. Я таким образом уже несколько сайтов спас от крэшей на мобильных устройствах :)
  • Аппаратное ускорение в жизни верстальщика. Семинар в Яндексе
    +1
    четвертый вариант — убрать пересечние блока с текстом и блока с анимацией?

    Нет, пересечения тут ни при чем, вынос происходит именно по z-стэку. Потому что браузер не может знать заранее, будут ли блоки пересекаться, если вы, например, анимируете их через JS.
  • Аппаратное ускорение в жизни верстальщика. Семинар в Яндексе
    +2
    … я увидел у слайда CSS свойство background-size: cover. Это свойство растягивает картинку на всю площадь блока… Ресайз картинки — это очень дорогостоящая операция, поэтому я отключил это CSS свойство и все стало совсем хорошо.


    Ресайз картинки — дорогая операция, но делается один раз на repaint. Поэтому проблема с производительностью не в других размерах у картинки, а в постоянной перерисовке блока. А это, скорее всего, из-за неправильной композиции.
  • Аппаратное ускорение в жизни верстальщика. Семинар в Яндексе
    +9
    Скорее всего вы видели что-то типа этого: 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) также «волшебно» ускорит страницу. Да, анимация будет быстрее, однако при неправильной композиции вы рискуете получить кучу проблем на скролле страницы или на банальном ховере на ссылках.
  • Анализ рендеринга через Skia Debugger: как можно найти самые дорогие для отрисовки элементы
    +22
    Спасибо за интересный обзор. В свою очередь хотел бы отметить следующее.

    В целом «притормаживание скролла» указывает на другую проблему, а именно композиция слоёв (layer compositing). Так как сегодня практически все браузеры используют GPU для отрисовки некоторых вещей, а отовсюду слышится «ставь translateZ(0) чтобы быстро и плавно всё» эта проблема становится очень актуальной.

    Если коротко, то в браузерах (как минимум на базе WebKit и Blink) есть набор триггеров, которые переносят некоторые слои на отдельную поверхность на GPU (в терминах Blink это перенос RenderLayer на свой GraphicsLayer). Эти триггеры могут быть как явно указаными у слоя (тот же translateZ(0), CSS-анимации на transform и opacity), так и косвенными, например, не-GPU слой по z-index’у находится выше GPU-слоя и их границы пересекаются.

    Вынос на GPU, помимо каких-то внутренних процессов, как правило сопровождается полной перерисовкой слоя, поэтому иногда можно наблюдать всякие «моргания» и прочие артефакты. На GPU такие слои фактически становятся текстурой на плоскости, которой удобно (а самое главное — очень дёшево) можно применять различные 3D-трансформации. Но тут есть один очень важный нюанс: если хотя бы один пиксель текстуры поменяется (например, на ховер, анимацию, что-то ещё) — её нужно заново перерисовать. Это очень сильно заметно, например, в WebKit на iOS. Соответственно, неумелое использование GPU-триггеров для «ускорения» страницы может на самом деле привести к очень серьёзным тормозам.

    Из всего вышесказанного конкретно для вашей ситуации: скорее всего, источник проблемы не в самом box-shadow, а в неправильной композиции, которая вызывает неявный вынос на GPU ненужных слоёв и, соответственно, перерисовку тени. Потому что при правильной композиции можно обвешаться различными эффектами и ничего не будет тормозить. Наверняка при включении “Show paint rectangles” вы наблюдали, что область перерисовки занимает всю станицу, хотя по-хорошему так быть не должно.

    Дебажить такие вещи очень удобно Safari Web Inspector: там есть отдельная панелька Layers, которая для выделенного элемента показывает, какие слои вынесены на GPU и, что особенно важно, причину такого выноса. Лично я уже нескольким ребятам помог сильно оптимизировать производительность с помощью этого инструмента, особенно для мобилок :)

    Чуть подробнее об этом можно почитать тут: www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
  • Emmet LiveStyle — инструмент для удобной front-end разработки
    +2
    Проблема source maps в том, что они годятся только для просмотра. Как только вы что-нибудь поменяете в сгенерированном CSS или в исходном файле препроцессора — source map становится невалидным и его нужно заново сгенерировать. В итоге для того, чтобы увидеть любое изменение, нужно сначала сохранить файл, дождаться, пока он перегенерируется, потом дождаться, пока Chrome по таймауту подцепит изменения. То есть не совсем «живое» редактирование.

    LiveStyle пытается иначе решить эту проблему: свойства в селекторах напрямую мапятся из CSS в препроцессор и наоборот. Тогда получается действительно живое редактирование, фрагмент показан в демо-видео. Маппинг селекторов, в большинстве случаев, относительно простой, но есть проблемы с маппингом миксинов, переменных и прочего. Поэтому я сейчас исследую, как это можно заставить работать правильно и удобно.
  • Emmet LiveStyle — инструмент для удобной front-end разработки
    +2
    Проблема подхода в Chrome Workspaces в том, что он становится бесполезным, если работаете с сайтом, где CSS собирается из нескольких файлов, а потом ещё и минифицируется. С LiveStyle таких проблем нет: вы сможете смапить два абсолютно разных файла (например, исходный модуль CSS в редакторе → скомпилированный CSS в браузере) и использовать их для живого редактирования.

    Ну и куча дополнительных плюшек вроде синхронизаций изменений между окнами, быстрое добавление нового файла и т.д.
  • Прощай, Zen Coding. Привет, Emmet!
    0
    Он пока не доведён до нужного мне состояния. Это влияет на то, как вы сможете расширять Emmet. В остальном он работает как надо.

    Разработчики Netbeans обещали ответить на мои вопросы, но пока молчат. Наверно, скоро «официально» выпущу этот плагин.
  • Прощай, Zen Coding. Привет, Emmet!
    0
    Лично я проблему чтения решаю другими инструментами вроде Code Outline в своём IDE. И «читаемость» в данном случае — довольно субъективное понятие, у того же HAML тоже есть проблемы с удобством редактирования, особенно на глубокой вложенности.

    И я не совсем понимаю, как синтаксис решает проблему редактирования? Например, если мне нужно быстро выделить определённый семантический элемент, или завернуть контент в новую обёртку, или удалить ненужный элемент, сохранив правильные отступы, как новый синтаксис поможет это сделать?
  • Прощай, Zen Coding. Привет, Emmet!
    0
    В Emmet куча действий, помогающих именно редактировать код.
  • Прощай, Zen Coding. Привет, Emmet!
    0
    Можно: github.com/sergeche/emmet-sublime#overriding-keyboard-shortcuts

    Но если не работает в синтаксисе HTML, значит, это проблема и я предлагаю перенести её обсуждение в трэкер.
  • Прощай, Zen Coding. Привет, Emmet!
    0
    Разворачивание по клавише Tab работает только для определённых синтаксисов, чтобы не конфликтовать с нативными сниппетами.

    Убедитесь, что синтаксис текущего документа выставлен, например, в HTML или CSS.
  • Прощай, Zen Coding. Привет, Emmet!
  • Прощай, Zen Coding. Привет, Emmet!
    –10
    Вадим, мы уже неоднократно говорили на эту тему. Я понимаю, что тебе она не дает покоя, но пора бы уже успокоиться и закрыть ее.

    Ты можешь спокойно развивать и разрабатывать Zen Coding (если можешь, конечно), разве тебе кто-то не дает это делать?
  • Прощай, Zen Coding. Привет, Emmet!
    –9
    Во-первых, это не код, а сниппеты в виде вики-страницы, которые как были в Zen Coding, так там и остались. И я никогда не скрывал, что ты являешься автором идеи Zen Coding.

    Во-вторых, в Emmet эти сниппеты сильно переработаны.

    В-третьих, я очень сильно сомневаюсь, что люди пользуются Zen Coding/Emmet только потому, что там такие классные сниппеты.

    И наконец, вместо того, чтобы постоянно проситься на страницу благодарностей, лучше сделать что-то, за что люди будут благодарны именно тебе.
  • Прощай, Zen Coding. Привет, Emmet!
    0
    Опишите, пожалуйста, проблемы в трэкере проекта.
  • Прощай, Zen Coding. Привет, Emmet!
    0
    Посмотрите, может, у вас похожая проблема: github.com/emmetio/emmet/issues/185
    Там же, внизу, есть новая версия плагина, которая может решить эти проблемы.

    И если у вас возникают проблемы с использованием плагина, напишите об этом, пожалуйста, в трэкере проекта.
  • Прощай, Zen Coding. Привет, Emmet!
    –14
    Хотя бы в раздел благодарностей вписал.

    В Благодарности вписаны только те, кто помогал разработке проекта.

    И я вам открою один маленький секрет: к первым реализациям (именно реализациям) Вадим Макеев не имеет абсолютно никакого отношения. Ради интереса можете прошерстить историю обновлений проекта. А то, что находится по указанной вами ссылке — всего лишь описание идеи, но никак не реализация.
  • Вышел Emmet v1.0
    0
    Если вы про HTML, то я бы в принципе не стал так делать.

    В Sublime Text нет возможности получить список нативных сниппетов. А это значит, что абсолютно все аббревиатуры мне нужно будет пропускать через себя (чтобы сделать исправление bntbtn) и игнорировать встроенные аббревиатуры (а это довольно серьёзная проблема).
  • Вышел Emmet v1.0
    0
    Можете привести пример?
  • Вышел Emmet v1.0
    0
    Уже начата работа над плагином для VS с бриджем через V8: github.com/sergey-rybalkin/emmet.net
  • Вышел Emmet v1.0
    0
    На питоне написана обёртка, которая запускает JS-код через PyV8.
  • Вышел Emmet v1.0
    +1
    А какой в этом смысл? Писать такие вещи на C/C++ гораздо сложнее, и такой код сложнее встраивать в существующие редакторы.

    Тем более, такой код нельзя запустить в браузере и добавить в такие замечательные сервисы, как jsfiddle.net и jsbin.com
  • Вышел Emmet v1.0
    +1
    Да, проблема с алертами была, но должна быть исправлена в финальной версии. Я перенёс код разворачивания аббревиатуры в другое место: алерт пропал, но сам триггер стал менее точным.
  • Вышел Emmet v1.0
    +1
    Да, планируется, просто в самом TM2 API как таковое отсутствует. Я попробую сделать контрибьют в код TM2 с теми методами, которые мне необходимы для создания плагина, и если его примут, то добавлю поддержку TM2.
  • Вышел Emmet v1.0
    0
    Нет, просто не хватает времени на всё. Поддержка VS в планах есть, даже был сделан прототип плагина: github.com/sergey-rybalkin/emmet.net
  • Вышел Emmet v1.0
    0
    А что вы подразумеваете под «чувствительностью»?
  • Вышел Emmet v1.0
    0
    Для Vim есть github.com/mattn/zencoding-vim
    Разработчики плагина стараются поддерживать фичи Emmet.

    У меня есть в планах создание официального плагина, но, признаюсь честно, пока останавливает незнание Vim как редактора и его принципов работы.
  • Готовим Sublime Text 2 для front-end
    0
    Emmet тоже работает с препроцессорами и у него есть нечёткий поиск, причём в стиле ST2: с отображением вариантов в автокомплите.