Pull to refresh
24
0
Константин Крамлих @PurplePowder

Пользователь

Send message

Готов за чашкой кофе обсудить как вращение деревьев, так и сложности с наймом разработчиков)

Привет! Спасибо!
Если честно, то по книгам не посоветую. Последний раз читал релевантные книги давным давно, когда писал трассировщик лучей :)
Почему бы не попробовать посмотреть как устроены библиотеки 2d графики, например, Skia или Blend2d? А про ту же Skia в интернетах можно найти design documents и какое-то количество выступлений разработчиков
Еще хорошая подборка статей про графику есть тут www.jendrikillner.com/article_database
Рад, что понравилось. Спасибо!
Добрый день!

Вызывает у меня это удивление вот почему: почему бы просто не очистить «почти всю память» у неактивных вкладок, а потом при переключении на вкладку просто перерисовать её полностью, с нуля. Это же не так долго. Или нет?

Тут сложно. Непонятно где проходит граница «почти всю». Вот если всю, то это будет в сущности discard, о котором я говорил в выступлении, но там появляются сложности — непонятно какую вкладку выгружать, а какую лучше не трогать. Тем не менее часть кэшей действительно протухают, если они какое-то время не использовались, например, видео на паузе уничтожают декодеры и очередь закешированных кадров. Но такие механизмы довольно сложно делать и в некоторых случаях невозможно сделать гарантированно работающее восстановление, например, что если мы очистили исходное содержимое страницы, а сервер работает так, что контент отдается ровно один раз (пример немного натянутый, но все же).

Что же он там так долго делает?..

Есть подозрение, что обновляет кеши, например сетевой. Но надо профилировать каждый конкретный случай, потому что может происходить примерно что угодно :)
Хорошее замечание! Да, доклады пересекаются (более того — в конце текущего есть ссылка на прошлый), но у них разные общие идеи. В прошлый раз я говорил с позиции экономии ресурсов, а тут кратко про то как работает отрисовка в браузере. Отрисовка — это одна из самых нагруженных частей браузера и ожидаемо, что нужно искать способы для экономии ресурсов в том числе и там
Можно посмотреть на browser://version. Текущая стабильная версия (19.3.0) базируется на 72 хромиуме. В поддержку писали через «сообщить о проблеме» в бутерброде?
Вопрос в том, нужно ли при этом ломать текущий Вёб полностью или лучше, что бы он хоть как-то работал, пусть в режиме совместимости, по запросу пользователя?

Такие фичи всегда катятся так, что пользователь может их выключить при желании, как минимум до тех пор пока проходит эксперимент.

Не вижу причин (кроме увеличения трудозатрат), почему бы не использовать и API, и пуши, и список от пользователей

Вполне может быть, что тут тоже будет такая возможность. В качестве примера можно привести флеш. Хром целенаправленно отказывается от него, но делает это относительно небольшими шажками:

  • Весь флеш играет всегда как хочет
  • Можно сделать так, чтобы играл по-умолчанию только важный флеш
  • Флеш блокируется, но есть вайтлист сайтов, где продолжает играть. Разблокировать можно через контекстное меню
  • Вайтлист сайтов сбрасывается после перезапуска

(Мы где-то тут, ниже вероятное развитие событий)

  • Вайтлиста нет, можно просто разблокировать
  • Разблокировать можно только с приседаниями
  • Флеш не поддерживается. Смерть флеша
Кэши — это не излишества. Кэши не создаются просто так без причины, они нужны для уменьшения времени получения ответа и для экономии других ресурсов, то есть это компромисс между памятью и cpu/батарейкой/сетью.
2-3 года назад в хромиуме был эксперимент, суть которого была в том, чтобы научиться собирать то, сколько памяти тратится на всякие разные кэши и при острой необходимости приходить и очищать их. Так вот это не только ничего не дало, но еще и сделало хуже. Да, это приводит к падению потребления памяти на краткий миг, но уже через ~1 секунду все кэши наполняются обратно, но вдобавок к этому всю эту секунду браузер работает очень неэффективно.

Если очень сильно хочется, то можно поэкспериментировать с флагами на chrome://flags или с ключами запуска (автоматически обновляемый список ключей хромиума есть тут peter.sh/experiments/chromium-command-line-switches). Беглый поиск строки «cache» подсказывает, что можно поиграться с размерами разных кэшей, но я не берусь давать тут советы, все зависит от большого количества факторов
Тут дело в том, что пока не совсем понятно будет ли это так сильно мешать пользователю. Если подумать и представить зачем фоновой вкладке что-то делать, то на ум приходит что-то в духе проигрывания звука, уведомлений, моргания тайтлом, обработки каких-то данных, etc. Планы же состоят не в том, чтобы просто все оторвать, а в том, чтобы дать какие-то понятные API, чтобы делать это более эффективно.
Например, когда-то давным давно сайты могли делать window.open в любой момент, чтобы обратить на себя внимание, потом это придушили, потому что таким подходом стали злоупотреблять. После этого с той же целью стали делать разные моргания тайтла. А сейчас можно отправлять пуши, которые даже более понятны юзеру, потому что требуют явного от него согласия и дают возможность отказаться от получения таких пушей. Вот и в остальных вещах должно быть также. Если вкладка хочет что-то сделать, то пользователь должен дать ей согласие и тогда у нее будет возможность продолжать это делать, может быть даже и в фоне.
Короче говоря такие изменения не должны никак затронуть пользовательский опыт, но будут менять то, как фронтендеры пишут сайты.

Что касается Яндекс.Браузера, то мы не катим бездумно все, что подмёрживаем себе от хромиума. Если наше продуктовое видение будет отличаться и будет потребность у пользователей в том, чтобы давать такую власть фоновым вкладкам, то мы будем думать как это сделать лучше.
Планировалось, что в основе будут ServiceWorker-ы. Выдержка из Background tabs & offscreen frames: further plans:
The work is underway on a set of APIs that developers will be able to use to specify which work needs to be done in the background, similar to what’s possible on Android and iOS. Service Workers will take the central place in this, with their capabilities enhanced by new features like being able to play audio, update page title & favicon, silent push notifications, and more

Но нужно следить за апдейтами в блоге developers.google.com/web/updates. Про все серьезные закручивания гаек там точно пишут.

Про то, будет ли у пользователя власть изменить решение браузера пока тоже непонятно, я не видел обсуждений этого вопроса. Но подозреваю, что в хроме такой возможности не будет
Все понимают, что есть такие ситуации, когда фоновая вкладка на самом деле не фоновая. Если вкладка играет звук или использует real-time connections, например, WebRTC или WebSockets, то она будет нормально работать и в фоновом режиме. То есть речь идет не о том, чтобы сломать всем веб, улучшить метрики и уйти, а о том, чтобы сделать лучше конкретному пользователю, не ухудшив его пользовательский опыт.
Проблема не только в рекламе. Некоторые сайты и без рекламы не очень эффективно сделаны.

В chromium-based браузерах можно использовать ключ --renderer-process-limit, чтобы ограничивать количество процессов рендереров. Вообще еще есть --single-process, но это скорее отладочный ключ и при этом браузер становится не очень работоспособным.
Тут, как это часто бывает, компромисс между экономией ресурсов и безопасностью. С учетом уязвимостей как в софте, так и в железе, очень хотелось, чтобы данные разных сайтов были изолированы друг от друга.

По поводу декодирования — это странно. В chromium уже давно есть GpuVideoDecoder, который с помощью DXVA декодирует видео. И это работает как на DX9, так и на DX11. Вопрос только в том, о каком кодеке идет речь: h.264 аппаратно поддерживается множеством разных карт, а вот с vp8/vp9 ситуация хуже. Если проблема еще актуальна, то стоит зарепортить баг
У нас в Яндекс.Браузере есть режим энергосбережения, в котором мы разрешаем сайтам играть видео только с помощью аппаратных декодеров, чтобы сэкономить батарейку.
Когда в 57 хроме начали троттлить таймеры, то частично сломали веб, потому что веб-разработчики не ожидали такого поворота, хотя чисто по стандарту нет гарантии того, что setTimeout вызовет функцию ровно через указанное время. Так что такие изменения должны осуществляться плавно, чтобы сайты успели к этому подготовиться.
Мне кажется, что так не было сделано сразу потому что раньше проблема стояла не так остро. Интернет был другой, не было 3d css, не было html5 video. Компьютеры были слабые, интернет медленный. Сайты разрабатывались с учетом всех этих ограничений. А сейчас ресурсов очень много и как-то уже перестали волноваться о проблемах эффективного их использования. Вот и пришла пора закручивать гайки.

Я бы для начала попробовал с помощью memory-infra посмотреть, чтобы примерно понять откуда ноги растут. Это вполне может быть какая-то утечка. Если повторяется более менее стабильно, то стоит отправить багрепорт с примерными шагами

Это внутренний профилировщик самого браузера. Вот тут подробнее

Просто венгерский язык принадлежит к финно-угорской группе. К ней еще, внезапно, принадлежат хантыйский и мансийский языки. Сама группа входит в уральскую языковую семью. Английский, русский, немецкий и т.д. — это языки индоевропейской семьи. Поэтому венгерский такой вот особенный европейский язык и знание других европейских языков особо может и не помочь в понимании
1

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Works in
Date of birth
Registered
Activity