Comments 26
Поправка: видеокарты всё-таки используют компрессию текстур, так что не всегда всё так печально, как с BMP.

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

А вы как-то мониторили занятые ресурсы на GPU?
Тема интересная, т.к. сложно предугадать заранее какой блок сколько памяти кушает.

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

В хроме во вкладке Rendering есть галка FPS Meter, и там среди прочего есть показатель потребления памяти GPU, очень помогает в работе.
Точно, раньше не обращал внимания, спасибо)
Да, вот на ней уже видна разница в выделении памяти при изменении размеров блока, здорово.
Хотя тоже не совсем очевидна работа, я вот зашел на несколько сайтов с огромной пачкой parallax анимаций на GSAP, он все анимации делает через transform: matrix() т.е. на GPU кидает железно и всегда, так там расход не поднимается выше 30mb.
Память я обычно смотрю в timeline с галочкой memory.
Сейчас глянул через Layers, отобразил блок, применил на нем translate3d, анимировал и расход памяти не меняется когда блок 500*500px и когда сделал его 200*200px. И даже когда ему тень добавил, хоть она и дорогая по ресурсам. Похоже и в timeline и тут идет речь не о GPU-шной RAM. Или размер блока, в случае когда это не растр, не влияет на количество выделяемой памяти.

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


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

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

Т.е. рутовый не захватывает в себя все остальные? Это же не совсем адекватно по каждому слою ходить смотреть и считать сумму)
1 2

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

Во вкладке Rendering, как посоветовал выше Zavtramen, как раз пишется общее количество занятой / максимальной GPU Memory. В Layers эти значения вообще странно себя ведут. И я не могу найти сайта (без WebGL, сейчас с ними посмотрю) на котором я завалю это значение больше 40mb из 512 доступных. Может приведете пример где память нерационально расходуется?
Не так давно я оптимизировал модуль отображения висивиг редактора сайтов. В нем страницы сдвигались по скролу, но через трансформы (там по другому никак). Там я видел значения превышающие 200 и более mb. Там было много проблем, но в итоге получилось более-менее решить все наладить и теперь видео память расходуется в несколько раз более экономично (если верить этому показателю, но в целом падения и лаги стали происходить гораздо реже). Поверх той логики которая отражена в статье, у браузеров всегда в рукаве огромное кол-во механизмов оптимизаций, поэтому утверждать что в вашей демке что-то не так с потреблением не стоит. Я думаю просто срабатывает одна из них. Как, например, если блоки с трансформами выносить за пределы вьюпорта то они перестают учитываться при расчете потребляемой памяти, возможно они вычищаются, или происходит что-то еще.

Годный материал! А для свг по потреблению памяти в зависимости от размеров (ширины, высоты) применяются те же правила? Вопрос в том, смогу ли сэкономить память уменьшив свг изображение с 1000px до 100px?

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

а есть какие-то негласные правила того, какого максимального кол-ва layer'ов стоит придерживаться?
допустим в хроме, 500 layers на страницу это уже перебор? или не страшно, если все они занимают килобайты?

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

Для меня самый большой минус в том, что GPU жрет батарейку моего ноутбука, а мне совсем не хочется тратить доп ресурсы для такого, казалось бы, не самого энергоемкого процесса как веб серфинг.
Что происходит на других мобильных устройствах? Полагаю что-то похожее.
Сварганил вариант на чистом CSS со скрпитингом(SASS).
Не считая задержки между циклами, от которых я пока не знаю как избавиться, выглядит вполне прилично ИМХО :)
https://codepen.io/dozenthoughts/pen/xRaJeW
>>iPhone 6 относится к дорогим high-end устройствам, на более доступных устройствах памяти гораздо меньше.

Как раз наоборот. На более дешёвых устройствах, памяти от 2Гб до 4 Гб. Нестоит равняться на iPhone, особенно учитывая его долю на рынке.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

26 April 2006

Location

Россия

Website

ok.ru

Employees

201–500 employees

Registered

9 August 2008