Firefox Quantum скоро появится. Он приносит ряд улучшений производительности, в том числе представленных в Servo.Чрезвычайно быстрый движок CSS.
Но большая часть технологии Servo еще не была представлена в Firefox Quantum, хотя и не за горами. Это WebRender, который является частью проекта Quantum Render и добавляется в Firefox.
WebRender известен своей чрезвычайной скоростью, но он не ускоряет рендеринг, а делает результат рендеринга более плавным.
С помощью WebRender мы хотим, чтобы приложения работали со скоростью 60 кадров в секунду (FPS) и выше: насколько страница меняется в каждом кадре, независимо от размера экрана. Это может быть сделано. В Chrome и текущих версиях Firefox некоторые страницы зависают со скоростью всего 15 кадров в секунду, в то время как60 кадров в секунду с WebRender.
Как WebRender это делает? Это коренным образом меняет способ работы движков рендеринга, делая их более похожими на движки 3D-игр.
Давайте посмотрим, что это должно сказать.
Работа рендерера
существуетСтатьи о СтилоВ статье я рассказал, как браузеры преобразуют HTML и CSS в пиксели на экране, и упомянул, что большинство браузеров делают это за пять шагов.
Эти пять шагов можно разделить на две части. Первая часть в основном строит план: средство визуализации объединяет HTML и CSS вместе с информацией, такой как размер области просмотра, чтобы определить, как должен выглядеть каждый элемент (ширина, высота, цвет и т. д.). Конечным результатом является дерево кадров, также известное как дерево рендеринга.
Другая часть — рисование и композитинг, чем занимается визуализатор. Средство визуализации преобразует результат предыдущего раздела в пиксели для отображения на экране.
Для одной и той же веб-страницы эта работа выполняется не один раз, а должна выполняться неоднократно. После изменения страницы (например, при переключении div) браузеру необходимо снова выполнить многие из этих шагов.
Даже если страница не изменилась (например, прокрутка страницы или выделение текста), браузеру все равно нужно выполнить некоторые шаги во второй части, а затем отобразить новое содержимое на экране.
Чтобы прокрутка, анимация и т. д. выглядели плавно, рендеринг должен выполняться со скоростью 60 кадров в секунду.
Возможно, вы слышали термин «кадры в секунду» (FPS), но не уверены, что он означает. Представьте, что у вас в руках книжка-раскладушка. Книга, полная статичных рисунков, быстро перелистывается пальцем, картинка как будто движется.
Чтобы анимация этого флипбука выглядела плавно, ему нужно переворачивать 60 страниц в секунду.
Эта книга состоит из рисунков. На бумаге много маленьких квадратов, и каждый квадрат можно закрасить только одним цветом.
Работа рендерера состоит в том, чтобы заполнить квадраты на чертеже. Заполните все квадраты на чертеже, и визуализация одного кадра завершена.
Конечно, реальных рисунков в компьютере нет. Это часть памяти, называемая кадровым буфером. Каждый адрес памяти в фреймбуфере похож на квадрат на рисунке... он соответствует пикселю на экране. Браузер заполнит каждую позицию числами, представляющими значения цвета в RGBA (красный, зеленый, синий и альфа-каналы).
Этот раздел памяти запрашивается, когда необходимо обновить дисплей.
Большинство компьютерных мониторов обновляются 60 раз в секунду. Вот почему браузеры пытаются отображать страницы со скоростью 60 кадров в секунду. Это означает, что у браузера есть 16,67 мс, чтобы выполнить всю работу (стилизация CSS, макет, рисование) и заполнить память фреймбуфера цветом пикселя. Время между двумя кадрами (16,67 мс) называется бюджетом кадра.
Иногда можно услышать, как люди говорят о пропущенных кадрах. Пропущенные кадры — это когда система не может завершить работу в рамках бюджета кадра. Прежде чем заполнение буфера цветом будет завершено, дисплей попытается прочитать новый кадр. В этом случае на мониторе снова будет отображаться старая информация о кадре.
Отбрасывание кадров похоже на вырывание страницы из флипбука. В результате анимация выглядит так, как будто она исчезает или прыгает, потому что страницы перехода между предыдущей и следующей страницами теряются.
Поэтому не забудьте поместить все пиксели в буфер кадра, прежде чем монитор снова проверит. Давайте посмотрим, как браузеры делали это раньше и что изменилось с тех пор. Есть возможности для улучшения.
Краткая история рисования и композитинга
Примечание. Рисование и композитинг — это самые разные места в разных механизмах рендеринга.Одноплатформенные браузеры (Edge и Safari) работают иначе, чем кроссплатформенные браузеры (Firefox и Chrome).
Даже самые ранние браузеры имели некоторые оптимизации, которые ускоряли отображение страниц. Например, при прокрутке страницы браузер сохранит ту часть, которая еще видна, и переместит ее. Затем нарисуйте новые пиксели в пустом месте.
Выясните, что изменилось, и обновите только измененные элементы или пиксели. Этот процесс называется аннулированием.
Позже браузеры стали применять больше методов аннулирования, например, аннулирование прямоугольника. Техника аннулирования прямоугольника находит наименьший прямоугольник экрана, который заключает в себе каждую измененную часть. Затем просто перерисуйте содержимое этих прямоугольников.
Это действительно может сэкономить много работы, когда страница практически не меняется. Например, курсор мерцает.
Но этого недостаточно, если меняется большая часть содержимого страницы. Так что есть новые технологии для решения этих ситуаций.
Введение в слои и композицию
Использование слоев намного проще, когда изменяются большие части страницы... по крайней мере, в некоторых случаях.
Слои в браузере очень похожи на слои в Photoshop или слои луковой кожицы, используемые в рисованной анимации. В основном это рисование разных элементов на разных слоях. Затем можно настроить относительную иерархию этих слоев.
Они всегда были частью браузеров, но не всегда для ускорения. Сначала они просто использовались, чтобы убедиться, что страница отображается правильно. Они соответствуют контекстам наложения.
Например, полупрозрачный элемент будет находиться в своем собственном контексте стека. Это означает, что у него есть собственный слой, поэтому вы можете смешивать его цвет с цветом под ним. Эти слои отбрасываются после завершения кадра. В следующем кадре все слои будут перерисованы заново.
Однако вещи в этих слоях часто не меняются от кадра к кадру. Подумайте об этой традиционной анимации. Фон не меняется, меняются только персонажи на переднем плане. Будет более эффективно сохранить и повторно использовать фоновый слой.
Это то, что делают браузеры. Он сохраняет эти слои. Затем браузер может перерисовывать только те слои, которые изменились. В некоторых случаях слои даже не менялись. Их просто нужно переставить: по экрану движется анимация, например, или что-то прокручивается.
Процесс организации слоев называется композитингом. Композитор начинает с этих двух частей:
-
Исходные растровые изображения: фон (включая пустое поле, занятое прокручиваемым содержимым) и само прокручиваемое содержимое.
-
Целевое растровое изображение: растровое изображение, отображаемое на экране.
Сначала компоновщик копирует фон в растровое изображение назначения.
Затем найдите часть прокручиваемого контента, которая должна отображаться. Скопируйте эту часть в растровое изображение назначения.
Это уменьшает количество рисунков на основной нити. Но это означает, что основной поток занимает много времени для составления. И есть много работы, конкурирующей за время в основной ветке.
Я уже говорил об этом раньше, основной поток немного похож на full stack разработчика. Он отвечает за DOM, макет и JavaScript. А также отвечает за рисование и композицию.
Столько миллисекунд, сколько основной поток тратит на отрисовку, композитинг, есть миллисекунды, недоступные для JavaScript и верстки.
А другая часть оборудования простаивает без дела. Это оборудование предназначено для графики. Это графический процессор. Игры используют ускорение графического процессора для рендеринга кадров с конца 90-х годов. С тех пор графические процессоры стали более мощными.
Композитинг с ускорением на GPU
Поэтому разработчики браузеров начали перекладывать все на GPU.
Есть две задачи, которые можно переложить на GPU:
1. Рисование слоя
2. Состав слоя
Перенести работу по рисованию на GPU может быть непросто. Так что в большинстве случаев кроссплатформенные браузеры по-прежнему потребляют ресурсы ЦП.
Но графический процессор может очень быстро выполнять композитинг, и его относительно легко перенести.
Некоторые браузеры идут еще дальше в этом параллельном подходе, добавляя поток компоновщика непосредственно на ЦП. Он управляет работой композитинга, которая происходит в графическом процессоре. Это означает, что если основной поток что-то делает (например, запускает JavaScript), поток компоновщика может выполнять другую работу, например, прокручивать контент во время прокрутки пользователем.
Это выводит всю работу над композицией из основного потока. Тем не менее, это оставляет много работы в основном потоке. Когда слой необходимо перерисовать, основной поток должен выполнить работу по рисованию, а затем передать слой графическому процессору.
Некоторые браузеры перемещают работу по рисованию в другой поток (в настоящее время Firefox работает над этим). Но перенос работы по рисованию на графический процессор происходит быстрее.
Рендеринг с ускорением на GPU
В результате браузеры также начали переносить работу по рисованию на GPU.
Этот переход все еще находится в стадии разработки. Некоторые браузеры всегда рисуют через графический процессор, другие могут делать это только на определенных платформах (например, Windows или мобильных устройствах).
Рендеринг на GPU может решить некоторые проблемы. ЦП освобождается, чтобы сосредоточиться на JavaScript и работе с макетом. Кроме того, GPU отрисовывает пиксели намного быстрее, чем CPU, поэтому он может рисовать быстрее. Это также означает, что меньше данных копируется из ЦП в ГП.
Однако сохранение этого различия между рендерингом и композитингом по-прежнему сопряжено с затратами, даже если оба они выполняются на графическом процессоре. Это различие также ограничивает типы оптимизации, которые можно использовать для ускорения работы графического процессора.
Это проблема, которую WebRender стремится решить. Это в корне меняет рендеринг, стирая различие между рисованием и композитингом. Такой подход к производительности средства визуализации обеспечивает наилучшее взаимодействие с пользователем в сегодняшней сети и наилучшую поддержку сетей будущего.
Это означает, что мы не просто хотим ускорить рендеринг кадров... мы хотим сделать рендеринг более последовательным, без мерцания. Даже при большом количестве пикселей, таких как монитор 4k или устройство WebVR, мы все равно хотим, чтобы процесс был более плавным.
Когда текущий браузер мерцает?
В некоторых случаях приведенные выше оптимизации могут ускорить отрисовку страницы. Когда на странице не так много изменений (например, мигает только курсор), браузер будет выполнять как можно меньше работы.
Разделение страницы на слои увеличивает преимущества этой оптимизации (расширяет количество оптимальных сценариев). Рисуя несколько слоев и заставляя их двигаться относительно друг друга, архитектура «краска + композитинг» работает очень хорошо.
Но использование слоев также сопряжено с компромиссами. Это займет довольно много памяти и может замедлить работу. Браузер должен комбинировать слои, которые имеют смысл. Но трудно сказать, что имеет смысл.
Это означает, что если на странице перемещается много разных вещей, слоев может быть слишком много. Эти слои заполняют память и требуют много времени для передачи в компоновщик.
В других случаях вы можете получить только один слой, когда вам нужно несколько слоев. Этот слой будет постоянно перерисовываться и передаваться в компоновщик, выполняющий работу по композитингу, ничего не меняя.
Это означает, что вы удвоили количество рисунков, дважды обрабатывая каждый пиксель, без всякой пользы. Быстрее визуализировать страницу напрямую, пропустив этап компоновки.
Есть также много ситуаций, когда слои не очень полезны. Если вы анимируете цвет фона, весь слой должен быть перерисован. Эти слои полезны только для нескольких свойств CSS.
Даже если большинство кадров в лучшем случае (то есть они занимают лишь небольшую часть бюджета кадра), движение все равно может быть прерывистым. Пока три или два кадра попадают в худший случай, будет ощутимое мерцание.
Эти ситуации называются обрывами производительности. Приложение работает плавно до тех пор, пока не обнаружатся эти наихудшие сценарии (такие как анимация фонового цвета), и частота кадров на мгновение балансирует на грани.
Тем не менее, эти обрывы производительности можно обойти.
Как это сделать? Следуйте по стопам движков 3D-игр.
Используйте GPU как игровой движок
Что, если перестать пытаться угадать, какие слои нужны? Что, если не учитывать различия между рисованием и композитингом, а учитывать только пиксели, отрисовываемые в кадре?
Это может показаться смешным, но на самом деле есть прецеденты. Современные видеоигры перерисовывают каждый пиксель и поддерживают 60 кадров в секунду более надежно, чем браузеры. Они сделали это неожиданным образом... они просто перерисовали весь экран, не создавая тех прямоугольников и слоев недействительности, которые минимизируют то, что рисуется.
Не будет ли рендеринг веб-страницы таким образом медленнее?
Это действительно медленнее, если вы используете процессор. Но для этого и нужны графические процессоры.
Графические процессоры предназначены для экстремальной параллельной обработки. я в предыдущем постеСтатьи о СтилоВопрос параллелизма обсуждался в . При параллелизме машины могут выполнять несколько операций одновременно. Количество задач, которые он может выполнять одновременно, зависит от количества ядер.
Процессоры обычно имеют от 2 до 8 ядер. Графические процессоры, как правило, имеют не менее нескольких сотен ядер, а часто и более 1000 ядер.
Хотя эти ядра работают по-разному. Они не работают полностью независимо, как ядра процессора. Вместо этого они обычно работают вместе, выполняя одни и те же инструкции в разных частях данных.
Это именно то, что нам нужно при заполнении пикселей. Каждый пиксель может быть заполнен другим ядром. Способный работать с сотнями пикселей одновременно, GPU намного быстрее, чем CPU при обработке пикселей... это правда, когда работают все ядра.
У графических процессоров очень строгие шаги, а их API очень ограничен, поскольку ядра должны делать одно и то же в одно и то же время. Давайте посмотрим, как это работает.
Во-первых, вам нужно сообщить графическому процессору, что рисовать. Это означает придание ему формы и указание, как его заполнить.
Для этого сначала разбейте рисунок на простые фигуры (обычно треугольники). Эти фигуры находятся в трехмерном пространстве, поэтому одни фигуры могут находиться позади других. Затем создайте массив координат x, y, z всех угловых вершин треугольника.
Затем выполните вызов отрисовки, сообщая графическому процессору, что нужно нарисовать эти фигуры.
Далее берет на себя GPU. Все ядра будут делать одно и то же одновременно. Они будут:
- Найдите все положения угловых вершин фигуры. Это называется затенением вершин.
- Найдите линии, соединяющие эти угловые вершины. Отсюда вы можете узнать, какие пиксели покрыты фигурой. Это называется растеризацией.
- Теперь, когда вы знаете пиксели, покрытые фигурой, вы можете выполнить итерацию по каждому пикселю, чтобы определить цвет этого пикселя. Это называется затенением пикселей.
Последний шаг можно сделать по-разному. Чтобы сообщить графическому процессору, что делать, вы передаете ему программу, называемую пиксельным шейдером. Затенение пикселей — одна из нескольких частей, программируемых в графическом процессоре.
Некоторые пиксельные шейдеры просты. Например, если фигура представляет собой одноцветную фигуру, программа шейдера должна возвращать только один и тот же цвет для каждого пикселя фигуры.
Другие более сложные, например, когда есть фоновое изображение, и вам нужно выяснить, какая часть изображения соответствует каждому пикселю. Вы можете масштабировать изображение, как художник... поместить сетку поверх изображения, соответствующую каждому пикселю. Таким образом, вам просто нужно знать область, которой соответствует пиксель, а затем выполнить цветовую выборку этой области. Это называется отображением текстуры, потому что оно отображает изображение (называемое текстурой) в пикселях.
Для каждого пикселя GPU вызывает программу пиксельного шейдера. Разные ядра могут работать параллельно над разными пикселями одновременно, но все они должны использовать одну и ту же программу пиксельного шейдера. Когда вы говорите графическому процессору рисовать фигуру, вы указываете ему, какой пиксельный шейдер использовать.
Практически для любой веб-страницы для разных частей страницы потребуются разные пиксельные шейдеры.
Шейдеры работают со всеми фигурами за одно отрисовку, поэтому часто бывает необходимо разделить работу отрисовки на группы. Они называются партиями. Чтобы максимально использовать все ядра, создайте определенное количество пакетов заданий, каждый из которых включает большое количество фигур.
Именно так работают графические процессоры по сотням или тысячам ядер. Именно из-за этого крайнего параллелизма мы можем думать о рендеринге всего в каждом кадре. Даже при таком крайнем параллелизме предстоит еще много работы. Чтобы это понять, нужно немного ума. А вот и WebRender...
Как WebRender использует GPU
Давайте вернемся назад и рассмотрим шаги, необходимые для отображения веб-страницы браузером. Здесь будет два изменения.
1. Больше нет различия между рисованием и композитингом. Все они являются частью одного и того же шага. Графический процессор одновременно выполняет команды графического API на основе переданных ему команд графического API.
2. Шаг компоновки приведет к другой структуре данных. Раньше это было дерево фреймов (или дерево рендеринга в Chrome). Теперь будет создан список отображения.
Список отображения представляет собой набор расширенных инструкций по рисованию. Он сообщает нам, что рисовать, и не указывает какой-либо графический API.
Всякий раз, когда есть что-то новое для рисования, основной поток передает список отображения в RenderBackend, который представляет собой код WebRender, работающий на ЦП.
Задача RenderBackend состоит в том, чтобы преобразовать этот список высокоуровневых инструкций по рисованию в вызовы отрисовки, необходимые графическому процессору, которые сгруппированы вместе в одном пакете для более быстрой работы.
Затем поток RenderBackend передаст эти пакеты потоку компоновщика, который, в свою очередь, передаст их графическому процессору.
Вызовы отрисовки, которые поток RenderBackend передает графическому процессору, должны выполняться как можно быстрее. Для этого используется несколько различных техник.
Удалите все ненужные фигуры из списка (ранняя отбраковка)
Лучший способ сэкономить время — ничего не делать.
Во-первых, RenderBackend может уменьшить количество отображаемых элементов списка. Он определит, какие элементы действительно появятся на экране. Для этого он будет смотреть на такие вещи, как расстояние прокрутки каждого поля прокрутки.
Если какая-то часть фигуры находится внутри прямоугольника, фигура будет включена в список, который необходимо нарисовать. В противном случае он будет удален. Этот процесс называется ранней выбраковкой.
Минимизировать количество промежуточных текстур (дерево задач рендеринга)
Теперь у вас есть древовидная структура, содержащая только те фигуры, которые будут использоваться. Это дерево организовано в контексты стека, как упоминалось ранее.
Такие эффекты, как фильтры CSS и контексты наложения, усложняют ситуацию. Предположим, есть элемент с прозрачностью 0,5, который содержит дочерние элементы. Вы можете подумать, что каждый дочерний элемент будет прозрачным... но на самом деле вся группа прозрачна.
Таким образом, группу необходимо сначала визуализировать как текстуру, при этом каждый дочерний элемент должен быть непрозрачным. Затем, когда к родительскому элементу добавляется дочерний элемент, можно изменить прозрачность всей текстуры.
Эти контексты наложения могут быть вложенными... родительский элемент может быть частью другого контекста наложения. Это означает, что его нужно отрендерить в другую промежуточную текстуру...
Создание пространства для этих текстур дорого. Мы хотим максимально сгруппировать элементы в одну и ту же текстуру перехода.
Чтобы помочь GPU сделать это, необходимо создать дерево задач рендеринга. С его помощью можно узнать, какие текстуры нужно создать перед другими текстурами. Любые текстуры, которые не зависят от других текстур, могут быть созданы в первый раз, что означает, что их можно комбинировать с этими промежуточными текстурами.
Итак, в приведенном выше примере мы сначала выводим один угол тени блока. (На самом деле немного сложнее, но суть в этом).
На втором проходе этот угол можно зеркально отразить и разместить на разных частях коробки. Затем группу можно сделать полностью непрозрачной.
Далее все, что нам нужно сделать, это изменить непрозрачность этой текстуры и поместить ее в окончательную текстуру, которую необходимо вывести на экран.
Построив это дерево задач рендеринга, вы сможете найти минимальное количество используемых внеэкранных целей рендеринга. Это нормально, как упоминалось ранее, создание пространства для этих целевых текстур рендеринга обходится дорого.
Это также облегчает пакетную обработку.
группировка вызовов отрисовки (пакетная обработка)
Как упоминалось ранее, необходимо создать определенное количество пакетов, и каждый пакет включает большое количество фигур.
Обратите внимание, что способ создания пакетов может действительно повлиять на скорость. Используйте как можно больше форм в одной партии. Это определяется несколькими причинами.
Во-первых, когда ЦП говорит графическому процессору выполнить вызов отрисовки, ЦП должен проделать большую работу. Например, запуск графического процессора, загрузка шейдерных программ и тестирование аппаратных ошибок и т. д. И пока CPU выполняет эту работу, GPU может простаивать.
Во-вторых, изменение состояния имеет свою цену. Предположим, вам нужно изменить шейдерные программы между партиями. На обычном графическом процессоре вам нужно дождаться, пока все ядра выполнят свою работу с текущим шейдером. Это называется осушением трубопровода. Остальные ядра не будут простаивать, пока конвейер не будет опустошен.
Поэтому партии содержат как можно больше вещей. Для типичного ПК вам нужно иметь 100 или меньше вызовов отрисовки на кадр с тысячами вершин на вызов. Это позволяет в полной мере использовать параллелизм.
Из дерева задач рендеринга вы можете узнать, что можно пакетировать.
В настоящее время для каждого типа примитивов требуется шейдер. Например, шейдер границы, шейдер текста, шейдер изображения.
Мы подумали, что можем объединить множество шейдеров, чтобы увеличить размер пакета. Но пока это неплохо.
Они готовы к отправке в GPU. Но на самом деле есть некоторые исключения, которые можно сделать.
Уменьшить затенение пикселей (Z-culling)
Большинство веб-страниц имеют большое количество перекрывающихся фигур. Например, текстовое поле находится внутри div с фоном, а этот div находится внутри body с другим фоном.
Когда графический процессор вычисляет цвет каждого пикселя, он может вычислить цвет пикселя в каждой форме. Но будет виден только верхний слой. Это называется перерисовкой и тратит время графического процессора.
Таким образом, мы можем сначала визуализировать верхнюю форму. При рисовании следующей фигуры, если встречается тот же пиксель, сначала проверьте, не существует ли уже значение. Пропустить, если есть значение.
Однако с этим есть небольшая проблема. Когда форма полупрозрачна, цвета двух фигур необходимо смешать. Чтобы он выглядел правильно, его нужно рисовать изнутри наружу.
Поэтому работу нужно разделить на две части. Сначала сделайте непрозрачную работу. Отрисовывает все непрозрачные формы снаружи внутрь. Пропускает пиксели, лежащие позади других пикселей.
Затем работайте над полупрозрачной формой. Работа ведется изнутри наружу. Если полупрозрачный пиксель падает поверх непрозрачного пикселя, он смешивается с непрозрачным пикселем. Если он будет отставать от непрозрачной формы, расчет игнорируется.
Разделение работы на две части, непрозрачность и альфа-каналы, пропускает ненужные вычисления пикселей, процесс, называемый Z-выборкой.
Это кажется простой оптимизацией, но для нас это был большой успех. На типичной веб-странице эта работа значительно уменьшает количество пикселей, которые нам нужно обработать, и в настоящее время мы смотрим, как перенести больше работы на шаг непрозрачности.
На данный момент у нас готово содержимое одного кадра. Мы сделали как можно меньше работы.
готов рисовать
Мы готовы запустить GPU и выполнить пакетный рендеринг.
Предупреждение: не все зависит от графического процессора
Процессору все еще нужно выполнить некоторую работу по рисованию. Например, мы по-прежнему используем ЦП для рендеринга символов (называемых глифами) в блоках текста. Это также возможно сделать на графическом процессоре, но трудно получить пиксельные эффекты, соответствующие глифам, которые компьютер отображает в других приложениях. Таким образом, шрифты, обработанные графическим процессором, будут выглядеть неряшливо. мы пытаемся пройтиПроект следопытаПеренесите работу, такую как глифы, на графический процессор.
В настоящее время они отображаются в растровое изображение процессором. Затем загрузите их в кеш текстур графического процессора. Этот буфер сохраняется между кадрами, потому что они обычно не меняются.
Хотя эта работа по рисованию выполняется центральным процессором, еще есть возможности для повышения скорости. Например, при отрисовке символов с определенным шрифтом мы разделим разные символы и отрисуем их отдельно, используя разные ядра. Это тот же метод, который Stylo использует для стиля параллельных вычислений... см.здесь.
Следующая работа WebRender
Ожидается, что WebRender появится в Firefox в 2018 году в рамках проекта Quantum Render, через несколько версий после выпуска Firefox Quantum. Это сделает современные веб-страницы более плавными. По мере увеличения количества пикселей на экране производительность рендеринга становится все более и более важной, поэтому WebRender также готовит Firefox к новой волне дисплеев с высоким разрешением 4K.
Но WebRender предназначен не только для Firefox. Это также важно для текущей работы над WebVR, где необходимо отображать разные кадры для каждого глаза со скоростью 90 кадров в секунду на дисплее 4K.
В настоящее время более ранние версии WebRender можно включить с помощью флага Firefox. Работа по интеграции все еще продолжается, поэтому производительность в настоящее время не так хороша, как когда работа по интеграции завершена. Если вы хотите следить за развитием WebRender, вы можете подписаться на репозиторий GitHub или подписаться на Firefox Nightly в Twitter, чтобы получать еженедельные обновления проекта Quantum Render.
Об авторе
Лин — инженер в команде по связям с разработчиками Mozilla. Она работает с JavaScript, WebAssembly, Rust и Servo и рисует кодовые комиксы.