Rendered size что это
Рендеринг веб сайтов 101
Вы вводите название сайта в адресную строку браузера, нажимаете enter, и по привычке видите запрашиваемую страницу. Все просто: ввел название сайта — сайт отобразился. Однако для более любознательных хочу рассказать, что происходит между тем как браузер начинает получать куски сайта (да, сайт приходит кусками, по-другому — чанками) и отображает полностью нарисованную страницу.
Как устроен браузер?
Перед историей о том, как браузер рисует страницу, важно понять как он устроен, какие процессы и на каком уровне выполняются. При знакомстве с процессом рендеринга мы не раз вспомним о компонентах браузера. Итак, под капотом браузер выглядит примерно следующим образом:
User Interface — это все что видит пользователь: адресная строка, кнопки вперед/назад, меню, закладки — за исключением области где отображается сайт.
Browser Engine отвечает за взаимодействие между User Interface и Rendering Engine. Например клик по кнопке назад должен сказать компоненте RE что нужно отрисовать предыдущее состояние.
Network выполняет xhr запросы за ресурсами, и в целом, общение браузера с остальным интернетом происходит через эту компоненту, включая проксирование, кэширование и так далее.
JS Engine место где парсится и исполняется js код.
UI Backend используется чтобы рисовать стандартные компоненты типа чекбоксов, инпутов, кнопок.
Data Persistence отвечает за хранение локальных данных, например в куках, SessionStorage, indexDB и так далее.
Далее узнаем как рассмотренные компоненты браузера взаимодействуют между собой и разберем подробнее, что происходит внутри Rendering Engine. Другими словами …
Как браузер переводит html в пиксели на экране?
Итак, с помощью компонента Network браузер начал получать html-файл чанками обычно по 8кб, что дальше? А далее идет процесс парсинга (спецификация процесса) и рендеринга этого файла в компоненте, как вы уже догадались — Rendering Engine.
Важно! Для повышения юзабилити, браузер не дожидается пока загрузится и распарсится весь html. Вместо этого браузер сразу пытается отобразить пользователю страницу (далее рассмотрим как).
Сам процесс парсинга выглядит так:
Результатом парсинга является DOM дерево. Возьмем к примеру такой html:
DOM дерево такого html файла будет выглядеть так:
Что такое рендеринг? И что такое рендер? Словарь разработчиков компьютерных игр!
В продолжении ликбеза по компьютерной графике как для программистов, так и для художников хочу поговорить о том что такое рендеринг. Вопрос не так сложен как кажется, под катом подробное и доступное объяснение!
Я начал писать статьи, которые являются ликбезом для разработчика игр. И поторопился, написав статью про шейдеры, не рассказав что же такое рендеринг. Поэтому эта статья будет приквелом к введению в шейдеры и отправным пунктом в нашем ликбезе.
Что такое рендеринг? (для программистов)
Итак, Википедия дает такое определение: Ре́ндеринг (англ. rendering — «визуализация») — термин в компьютерной графике, обозначающий процесс получения изображения по модели с помощью компьютерной программы.
Довольно неплохое определение, продолжим с ним. Рендеринг — это визуализация. В компьютерной графике и 3д-художники и программисты под рендерингом понимают создание плоской картинки — цифрового растрового изображения из 3д сцены.
То есть, неформальный ответ на наш вопрос «Что такое рендеринг?» — это получение 2д картинки (на экране или в файле не важно). А компьютерная программа, производящая рендеринг, называется рендером (англ. render) или рендерером (англ. renderer).
Рендер
В свою очередь словом «рендер» называют чаще всего результат рендеринга. Но иногда и процесс называют так же (просто в английском глагол — render перенесся в русский, он короче и удобнее). Вы, наверняка, встречали различные картинки в интернете, с подписью «Угадай рендер или фото?». Имеется ввиду это 3D-визуализация или реальная фотография (уж настолько компьютерная графика продвинулась, что порой и не разберешься).
Виды рендеринга
В зависимости от возможности сделать вычисления параллельными существуют:
Существует много алгоритмов рендеринга, но все их можно разделить на две группы по принципу получения изображения: растеризация 3д моделей и трасировка лучей. Оба способа используются в видеоиграх. Но трасировка лучей чаще используется не для получения изображений в режиме реального времени, а для подготовки так называемых лайтмапов — световых карт, которые предрасчитываются во время разработки, а после результаты предрасчета используются во время выполнения.
В чем суть методов? Как работает растеризация и трасировка лучей? Начнем с растеризация.
Растеризация полигональной модели
Сцена состоит из моделей, расположенных на ней. В свою очередь каждая модель состоит из примитивов.
Это могут быть точки, отрезки, треугольники и некоторые другие примитивы, такие как квады например. Но если мы рендерим не точки и не отрезки, любые примитивы превращаются в треугольники.
Задача растеризатора (программа, которая выполняет растеризацию) получить из этих примитивов пиксели результирующего изображения. Растеризация в разрезе графического пайплайна, происходит после вершинного шейдера и до фрагментного (Статья про шейдеры).
*возможно следующей статьёй будет обещанный мной разбор графического пайплайна, напишите в комментариях нужен ли такой разбор, мне будет приятно и полезно узнать скольким людям интересно это всё. Я сделал отдельную страничку где есть список разобранных тем и будущих — Для разработчиков игр
В случае с отрезком нужно получить пиксели линии соединяющей две точки, в случае с треугольником пиксели которые внутри него. Для первой задачи применяется алгоритм Брезенхема, для второй может применяться алгоритм заметания прямыми или проверки барицентрических координат.
Сложная модель персонажа состоит из мельчайших треугольников и растеризатор генерирует из неё вполне достоверную картинку. Почему тогда заморачиваться с трассировкой лучей? Почему не растеризовать и все? А смысл вот в чем, растеризатор знает только своё рутинное дело, треугольники — в пиксели. Он ничего не знает об объектах рядом с треугольником.
А это значит что все физические процессы которые происходят в реальном мире он учесть не в состоянии. Эти процессы прямым образом влияют на изображение. Отражения, рефлексы, тени, подповерхностное рассеивание и так далее! Все без чего мы будем видеть просто пластмассовые модельки в вакууме…
А игроки хотят графоний! Игрокам нужен фотореализм!
И приходится графическим программистам изобретать различные техники, чтобы достичь близости к фотореализму. Для этого шейдерные программы используют текстуры, в которых предрассчитаны разные данные света, отражения, теней и подповерхностного рассеивания.
В свою очередь трассировка лучей позволяет рассчитать эти данные, но ценой большего времени рассчета, которое не может быть произведено во время выполнения. Рассмотрим, что из себя представляет этот метод.
Трасировка лучей (англ. ray tracing)
Помните о корпускулярно волновом дуализме? Напомню в чем суть: свет ведёт себя и как волны и как поток частиц — фотонов. Так вот трассировка (от англ «trace» прослеживать путь), это симуляция лучей света, грубо говоря. Но трассирование каждого луча света в сцене непрактично и занимает неприемлемо долгое время.
Мы ограничимся относительно малым количеством, и будем трассировать лучи по нужным нам направлениям.
А какие направления нам нужны? Нам надо определять какие цвета будут иметь пиксели в результирующей картинке. Тоесть количество лучей мы знаем, оно равно количеству пикселей в изображении.
Что с направлением? Все просто, мы будем трассировать лучи в соответствии с точкой наблюдения (то как наша виртуальная камера направлена). Луч встретится в какой-то точке с объектом сцены (если не встретится, значит там темный пиксель или пиксель неба из скайбокса, например).
При встрече с объектом луч не прекращает своё распространение, а разделяется на три луча-компонента, каждый из которых вносит свой вклад в цвет пикселя на двумерном экране: отражённый, теневой и преломлённый. Количество таких компонентов определяет глубину трассировки и влияет на качество и фотореалистичность изображения. Благодаря своим концептуальным особенностям, метод позволяет получить очень фотореалистичные изображения, однако из-за большой ресурсоёмкости процесс визуализации занимает значительное время.
Рендеринг для художников
Но рендеринг это не только программная визуализация! Хитрые художники тоже используют его. Так что такое рендеринг с точки зрения художника? Примерно то же самое, что и для программистов, только концепт-художники выполняют его сами. Руками. Точно так же как рендерер в видео-игре или V-ray в Maya художники учитывают освещение, подповерхностное рассеивание, туман и др. факторы, влияющие на конечный цвет поверхности.
К примеру картинка выше, поэтапно прорабатывается таким образом: Грубый скетч — Лайн — Цвет — Объем — Рендер материалов.
Рендер материалов включает в себя текстурирование, проработку бликов — металлы, например, чаще всего очень гладкие поверхности, которые имеют четкие блики на гранях. Помимо всего этого художники сталкиваются с растеризацией векторной графики, это примерно то же самое, что и растеризация 3д-модели.
Растеризация векторной графики
Суть примерно такая же, есть данные 2д кривых, это те контуры, которыми заданы объекты. У нас есть конечное растровое изображение и растеризатор переводит данные кривых в пиксели. После этого у нас нет возможности масштабировать картинку без потери качества.
Читайте дальше
Статьи из рубрики «Ликбез для начинающих разработчиков игр«, скорее всего окажутся очень для Вас полезными, позвольте-с отрекомендовать:
Послесловие
В этой статье, я надеюсь, вы осили столько букв, вы получили представление о том, что такое рендеринг, какие виды рендеринга существуют. Если какие-то вопросы остались — смело задавайте их в комментариях, я обязательно отвечу. Буду благодарен за уточнения и указания на какие-то неточности и ошибки.
Дорогой друг! Тебе есть что сказать? Понравился пост? Не стесняйся! Оставь комментарий, нам очень важно ТВОЕ мнение
Новое CSS-свойство content-visibility ускоряет отрисовку страницы в несколько раз
5 августа 2020 разработчики Google анонсировали новое CSS-свойство content-visibility в версии Chromium 85. Оно должно существенно повлиять на скорость первой загрузки и первой отрисовки на сайте; причём с только что отрендеренным контентом можно взаимодействовать сразу же, не дожидаясь загрузки остального содержимого. content-visibility заставляет юзер-агент пропускать разметку и покраску элементов, не находящихся на экране. По сути, это работает как lazy-load, только не на загрузке ресурсов, а на их отрисовке.
Поддержка
content-visibility основывается на примитивах из спецификации CSS Containment. Хотя на данный момент content-visibility поддерживается только в Chromium 85 (и считается «достойным прототипирования» в Firefox), спецификация Containment поддерживается в большинстве современных браузеров.
Принцип работы
Основная цель CSS Containment — повысить производительность рендеринга веб-контента, обеспечивая предсказуемую изоляцию поддерева DOM от остальной части страницы.
По сути, разработчик может сообщить браузеру, какие части страницы инкапсулированы как набор контента, что позволяет браузерам оперировать контентом без необходимости учитывать состояние вне поддерева. Браузер может оптимизировать рендеринг страницы, зная, какие поддеревья содержат изолированный контент.
Всего есть четыре типа CSS Containment, каждое выступает значением для CSS-свойства contain и может быть скомбинировано с другими:
Пропускаем рендеринг с content-visibility
В автоматическом режиме свойство получает атрибуты layout, style и paint, а при выходе элемента за края экрана, получает size и перестаёт красить и проверять содержимое. Это значит, что как только элемент выходит из зоны отрисовки, его потомки перестают рендериться. Браузер распознает размеры элемента, но больше не делает ничего, пока в отрисовке не возникнет необходимость.
Пример — тревел-блог
Обычно в тревел-блоге есть несколько историй с изображениями и описания. Вот что происходит в типичном браузере, когда он переходит на тревел-блог:
Теперь представим, что мы поместили content-visibility: auto на каждый пост в блоге. Основная система та же: браузер загружает и рендерит части страницы. Однако, разница в количестве работы, сделанной в шаге 2. С content-visibility браузер будет стилизовать и размещать тот контент который сейчас видит пользователь (на экране). Но обрабатывая истории вне экрана, браузер будет пропускать рендеринг всего элемента и будет размещать только контейнер. Производительность загрузки этой страницы будет как если бы она содержала заполненные посты на экране и пустые контейнеры для каждого поста вне его. Так получается гораздо быстрее, выигрыш составляет до 50% от времени загрузки. В нашем примере мы видим улучшение с 232мс рендеринга до 30мс, это улучшение производительности в 7 раз.
Что нужно сделать чтобы воспользоваться этими преимуществами? Во-первых, мы разделяем контент на части:
После, мы применяем последующую стилизацию на части:
Обратите внимание, что когда контент перемещается с экрана, он будет рендериться по необходимости. Однако, это не означает что браузер должен будет рендерить один и тот же контент раз за разом, ведь работа рендеринга сохраняется, когда это возможно.
Определение типичного размера элемента с contain-intrinsic-size
Скрываем контент с content-visibility: hidden
content-visibility: hidden делает то же, что и content-visibility: auto делает с контентом вне экрана. Однако, в отличие от auto, он не начинает автоматический рендеринг контента на экране.
Сравним его с обычными способами спрятать контент элемента:
Заключение
content-visibility и CSS Containment Spec позволяют значительно ускорять рендеринг и загрузку страниц без каких-либо сложных манипуляций, на голом CSS.
The CSS Containment Spec
MDN Docs on CSS Containment
CSSWG Drafts
При подготовке материала использовалась следующая информация — web.dev/content-visibility
На правах рекламы
Серверы для размещения сайтов — это про наши эпичные! Все серверы «из коробки» защищены от DDoS-атак, автоматическая установка удобной панели управления VestaCP. Лучше один раз попробовать 😉
Как сделать изображения адаптивными с помощью CSS
Большинство сегодняшних сайтов адаптивны. А если в нём нужно центрировать и выровнять изображение, необходимо научиться делать изображения плавными или адаптивными с помощью CSS.
Пару недель назад я опубликовал обучающее видео, в котором объяснил, как сделать адаптивный веб-сайт. В видео мы сделали изображение адаптивным. В этом посте я хотел бы рассказать об этом подробнее.
Также вы узнаете некоторые общие проблемы, которые могут возникнуть при попытке сделать изображения адаптивными. Я постараюсь объяснить, как их решить.
Сделать изображение гибким или отзывчивым на самом деле довольно просто. Когда вы загружаете изображение на веб-сайт, оно имеет ширину и высоту по умолчанию. Вы можете изменить их с помощью CSS.
Чтобы изображение было отзывчивым, нужно присвоить новое значение его свойству width. Тогда высота изображения автоматически изменится.
Важно знать, что вы всегда должны использовать относительные единицы для свойства ширины, такие как процент, а не абсолютные единицы, такие как пиксели.
Например, если вы определите фиксированную ширину 500 пикселей, ваше изображение не будет отзывчивым, потому что единица измерения абсолютная.
Вот почему вам следует вместо этого назначить относительную единицу, например 50%. Такой подход сделает ваши изображения плавными, и они смогут изменять свой размер независимо от размера экрана.
Один из вопросов, который мне задают чаще всего, — следует ли использовать медиа-запросы.
Медиа-запрос — еще одна важная функция CSS, которая помогает сделать веб-сайт адаптивным. Я не буду вдаваться в подробности, но вы можете прочитать другой мой пост позже, чтобы узнать, как использовать медиа-запросы более подробно.
Ответ на этот вопрос: «это зависит от обстоятельств». Если хотите, чтобы изображение имело разные размеры от одного устройства к другому, нужно будет использовать медиа-запросы. В противном случае вы этого не сделаете.
Теперь для этого примера ваше изображение имеет ширину 50% для любого экрана. Но если вы хотите сделать его полноразмерным для мобильных устройств, понадобится помощь медиа-запросов:
Таким образом, в соответствии с правилом медиа-запроса любое устройство размером менее 480 пикселей будет занимать всю ширину экрана.
Другой способ, которым разработчики могут создавать адаптивные изображения, — это свойство max-width. Однако это не всегда лучший метод, поскольку он может работать не для всех размеров экрана и устройств.
Прежде чем перейти к примеру, необходимо понять, что именно делает свойство max-width.
Свойство max-width устанавливает максимальную ширину для элемента, которая не позволяет ширине этого элемента быть больше, чем его значение max-width (но может быть меньше).
Например, если изображение имеет ширину по умолчанию 500 пикселей, а размер вашего экрана всего 360 пикселей, вы не сможете увидеть полное изображение, потому что недостаточно места:
Поэтому вы можете определить свойство max-width для изображения и установить его на 100%, что сжимает изображение с 500 до 360 пикселей. Таким образом, вы сможете увидеть полное изображение на экране меньшего размера.
Хорошо то, что, поскольку вы используете относительные единицы, изображение будет плавным на любом устройстве размером менее 500 пикселей.
К сожалению, размер экрана будет несколько больше 500 пикселей, но изображение не изменится, поскольку его ширина по умолчанию составляет 500 пикселей. Такой подход нарушит отзывчивость изображения.
Чтобы исправить это, вам нужно снова использовать свойство width, что делает бесполезным свойство max-width.
Другая распространенная проблема, с которой вы можете столкнуться, связана со свойством высоты. Обычно высота изображения автоматически изменяется, поэтому вам не нужно назначать свойство высоты вашим изображениям (потому что это как бы ломает изображение).
Но в некоторых случаях вам, возможно, придется работать с изображениями, которые должны иметь фиксированную высоту. Поэтому, когда вы назначаете фиксированную высоту изображения, оно все равно будет отзывчивым, но не будет хорошо выглядеть.
Рендеринг WEB-страницы: что об этом должен знать front-end разработчик
Приветствую вас, уважаемые хабравчане! Сегодня я бы хотел осветить вопрос рендеринга в веб-разработке. Конечно, на эту тему уже написано много статей, но, как мне показалась, вся информация довольно разрознена и отрывочна. По крайней мере, чтобы собрать всю картину в своей голове и осмыслить её, мне пришлось проанализировать немало информации (в основном — англоязычной). Именно поэтому я решил формализовать свои знания в статью, и поделиться результатом с сообществом Хабра. Думаю, информация будет полезна как начинающим веб-разработчикам, так и более опытным, чтобы освежить и структурировать свои знания.
Данное направление можно и нужно оптимизировать на этапе вёрстки/frontend-разработки, поскольку, очевидно, что разметка, стили и скрипты принимают в рендеринге непосредственное участие. Для этого соответствующие специалисты должны знать некоторые тонкости.
Отмечу, что статья нацелена не на точную передачу механики работы браузеров, а, скорее, на понимание её общих принципов. Тем более, разные браузерные движки сильно отличаются в алгоритмах работы, поэтому охватить все нюансы в рамках одной статьи не представляется возможным.
Процесс обработки WEB-страницы браузером
Для начала, рассмотрим последовательность работы браузера при отображении документа:
Repaint
Reflow
Если же изменения затрагивают содержимое, структуру документа, положение элементов — происходит reflow (или relayout). Причинами таких изменений обычно являются:
Оптимизация со стороны браузера
Браузеры по возможности локализуют repaint и reflow в пределах элементов, подвергнувшимися изменению. Например, изменение размеров абсолютно или фиксировано спозиционированного элемента затронет только сам элемент и его потомков, в то время как изменение статично спозиционированного — повлечет reflow всех элементов, следующих за ним.
Ещё одна особенность — во время выполнения JavaScript браузеры кэшируют вносимые изменения, и применяют их в один проход по завершению работы блока кода. Например, в ходе выполнения данного кода произойдет только один reflow и repaint:
Однако, как описано выше, обращение к свойствам элементов вызовет принудительный reflow. То есть, если мы в приведённый блок кода добавим обращение к свойству элемента, это вызовет лишний reflow:
В итоге мы получим 2 reflow вместо одного. Поэтому, обращения к свойствам элементов по возможности нужно группировать в одном месте, дабы оптимизировать производительность (см. более подробный пример на JSBin).
Затем, попробуем реализовать задуманное следующим образом:
Данное решение не будет работать, как ожидается, т.к. изменения кэшируются и применяются только в конце блока кода. Нас выручит принудительный reflow, в результате код приобретёт следующий вид, и будет в точности выполнять поставленную задачу:
Практические советы по оптимизации
На основе данной статьи, а также других статей на Харбе, где освещается вопрос оптимизации клиентской части, можно вывести следующие советы, которые пригодятся при создании эффективного фронтенда:
Надеюсь, каждый читатель извлёк из статьи что-нибудь полезное. В любом случае — спасибо за внимание!
UPD: Спасибо SelenIT2 и piumosso за верные замечания по поводу эффективности обработки CSS-селекторов.