Pull to refresh

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. Там было много проблем, но в итоге получилось более-менее решить все наладить и теперь видео память расходуется в несколько раз более экономично (если верить этому показателю, но в целом падения и лаги стали происходить гораздо реже). Поверх той логики которая отражена в статье, у браузеров всегда в рукаве огромное кол-во механизмов оптимизаций, поэтому утверждать что в вашей демке что-то не так с потреблением не стоит. Я думаю просто срабатывает одна из них. Как, например, если блоки с трансформами выносить за пределы вьюпорта то они перестают учитываться при расчете потребляемой памяти, возможно они вычищаются, или происходит что-то еще.
В Firefox https://ru.4game.com/chaos-fighters/ без GPU-отрисовки очень тормозит, с GPU-отрисовкой лучше, но не идеально (в Linux она выключена по умолчанию). Тем не менее, в Chromium все плавно.

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

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

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

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

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

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

>>iPhone 6 относится к дорогим high-end устройствам, на более доступных устройствах памяти гораздо меньше.

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