Comments 60
Апд: Хотя и в нормальном режиме там 80G виртуальной памяти выделено, так что хз…
Ещё в 10.14 так и не починили Preview для просмотра jpeg, а в iOS 12 как был глюк в Books со сбрасыванием размера страницы (pdf) при её случайном покачивании из стороны в сторону, так и остался.
Всё браузеры под iOS работают на WebKit, от Apple даже chrome
— Проверил на дирижабле — ничего подобного.
Там вполне конечная рекурсия, просто очень затратная. backdrop-filter — это очень дорогая операция.
А почему в хроме эта страница имеет бесконечную высоту не сообщается?
При ручном листании правда устанешь ждать, но бегунком на скроллбаре вполне пролистывается до конца.
При этом проблем со стабильностью или производительностью в Хроме или Лисе подобная страница не вызывает — памяти съедает не больше 100 Мб, что по меркам современных ожиревших браузеров норма, процессор особо не грузит. Тот же статья на харбре или ЖЖ с несколькими сотнями комментариев и памяти и ресурсов процессора больше жрут.
Хром при этом показывает все в точности как и было задумано «дизайнером»: там же в сходном в коде несколько тысяч блоков в которых через стили прописаны размеры 10000 х 10000 пикселей. Так что при отображении «в лоб» и должна получаться страничка в миллионы пикселей высотой.
А вот Лиса «халтурит» — видимо потому что эти блоки пустые (без контента) и рендерит только 1й.
Там в исходном в коде несколько тысяч вложенных друг в друга блоков в которых через стили прописаны размеры 10000 х 10000 пикселей. То есть все вместе они должны занимать 10000 х 10000 пикселей, что корректно отображает ФФ и Сафари, если убрать backdrop-filter.
При этом проблем со стабильностью или производительностью в Хроме или Лисе подобная страница не вызывает
Еще бы вызывала, в них же нет никаких backdrop-filter.
1 ядро загружено на 100%, потребление памяти, кажется, не растёт.
Несколько секунд подтормаживания, потом сильно размытые блюром рожицы как пложено показываются. Загрузка процессора при открытии и при скроллинге высокая, но если скролл не дергать то, то не грузит.
Потребление памяти тоже в норме.
А вот новых ФФ (квантум) при попытке открытия сразу выжирают всю доступную память (в моем случае около 10 ГБ) и на 100% грузит одно из ядер процессора. Но все-равно ничего не падает — ОС предупреждает о нехватке памяти, но все продолжает работать нормально, включая сам браузер — другие открытые в нем вкладки работают нормально и даже не тормозят.
Update:
Если поняблюдать за потреблением памяти в новом ФФ, то оно после скачка до максимума (предела доступной в системе памяти) начинает постепенно снижаться.
Решил посмотреть чем закончится? В результате минут через 5 он все-таки смог открыть и нормально показать такую страничку. При этом уже не тормозя и не пожирая память.
Дальше уже от корректности обработки таких неадеватных запросов приложения (в данном случае браузера) со стороны ОС(в данном примере iOS) зависит.
Адекватно — отдать приложению сколько есть свободной, не нарушая работу других программ и ядра, кроме общего замедления работы (из-за начавшегося активного свопа на диск к примеру и снижения размера дискового кэша до минимума).
Неадекватно — упасть в «синьку» или уйти в ребут от таких «жадных» запросов прикладного софта.
Ну тогда не понятно в чем проблема. Блюр фильтр конечно довольно ресурсоемкая вещь, но не то, чтобы критически. Попробовал в фотошопе открыть картинку на 100 Мегаписклей (10000 х 10000) и применить к ней всей гаус-блюр с радиусом размытия 10px как в примере.
Никаких проблем — секунд на 5-7 работы на уже 10 летней давности процессоре и около 700 МБ использованной памяти.
В FF ниже рабочий пример выложили, он тоже без проблем открывается. При скролинге такой странички правда жутко тормозит, но не только ОС, но и сам браузер (остальные вкладки) продолжают работать без проблем, никаких зависаний или вылетов. После закрытия вкладки подторможивания браузера сразу прекращаются.
Потребление памяти тоже умеренное — где-то +300-400 Мб при открытии.
Возможно в сафари такой же глюк как и хроме и он вложенные дивы пытается последовательно вывести и умирает при попытке наложения фильтра на картинку размером в несколько десятков гигапикселей (10000 х несколько миллионов) вместо 100 MPx как должно быть при корректном отображении?
У кого сафари под iOS под рукой — можете проверить убрав фильтр, но оставив ту же страничку с диком количеством вложенных див-ов — как будет открисоывать?
1. После открытия подобной страницы Лиса «заражается» — при последующих запусках, один из ее процессов начинает сразу со старта жрать по 5 ГБ памяти и грузить на максимум одно ядро. И дело вовсе не в автоматически открывающейся вкладке с стараницей (из сохраненной сессии к примеру) — открытых видимых вкладок НЕТ, новые владки открывают без проблем. Но через дисперчер задач видно, что где-то во внутренностях он продолжает фигней страдать в одном из скрытых процессов (чем занимается этот процесс вообще фиг знает — браузер на его прибитие вообще никак не реагирует). И даже очистка кэша/истории не помогает, лечится только полной очисткой браузера (сносом профиля — Информация для решения проблем ==> очистка FireFox)
2. Оказалось, что у меня и на той машине не самая свежая версия стояла. Обновился до последней (62й) — там уже не только мгновенно сжирает всю память, но и системе плоховато становится. До зависаний и перезагрузок правда не доходит, но процесс system (ntoskrln.exe) грузит процессор на максимум и тормозит и подглючивает уже вообще вся система, а не только браузер.
В какой раз убеждаюсь, что чем дальше тем хреновее делают современный браузеры. Что-то улучшили, свистелок-перделок добавили, зато вместо с ними добавили пачку глюков, в очередной раз прибавили жор ресурсов, опционально поломали совместимости.
На этом аномальном примере особо выпукло заметно:
FF 47-52: Открывается без проблем, подтормаживает секунд 5 при открытии, потребление памяти нормальное, на систему и даже другие вкладки никак не влияет
FF 57: При открытии жестко тормозит несколько минут, постепенно сжирает всю доступную память, но работу остальной системы не нарушает, кроме как перетягивания на себя ресурсы (в основном памяти + 1 ядро под постоянной загрузкой)
FF 62: Мгновенно сжирает всю доступную память + практически вешает систему нарушая работу всех программ — несколько работавших сразу вылетили с ошибками.
Блюр фильтр конечно довольно ресурсоемкая вещь, но не то, чтобы критически. Никаких проблем — секунд на 5-7 работы на уже 10 летней давности процессоре.
Вы продолжаете «не обращать внимание». Backdrop-filter накладывается не на содержимое элемента, а на фон, который под ним. А фоном для элемента в том числе является родительский элемент. А там 3485 вложенных элементов. Более того, это фильтр гауссова размытия, так что для того, чтобы отрисовать экран 1000x1000 пикселей, нужно взять фон примерно 1030x1030 пикселей под ним. В результате уже где-то на 300-м элементе и дальше нужно размывать все 10000x10000 пикселей, а не только то, что видно на экране.
Возможно в сафари такой же глюк как и хроме и он вложенные дивы пытается последовательно вывести
Я уже выше писал, что нет, Сафари верно показывает вложенные дивы. Более того, если располагать элементы последовательно, нет никакой проблемы это отрисовать — нужно будет отрисовывать только то, что на экране, а на экране строго фиксированное количество пикселей, еще и пустых в случае filter, а не backdrop-filter.
MacAir OS X Yosemitec 10.10.5 — никаких проблем. Safari
На div был повешен обработчик onclick и на устройствах iOs клик не срабатывал. Добавил диву style: «cursor: pointer;», в результате страница стала тупо зависать на устройствах iOs при клике по этому диву. Устройство при этом хорошо разогревалось.
Проблема решилась заменой дива на «а»
Chrome за флагом поддерживает backdrop-filter
, если включить, то вместо браузера получаем чёрный прямоугольник. На систему, благо, никак не влияет (Windows).
Хром — нормально
Опера — нормально
Лиса — схалтурила и загрузила не всё, похоже стоит ограничение на глубину рекурсии
Edge — отказался грузить
IE 11 — отказался грузить
MacBook PRO 15, 2017
iOS CSS of death