Comments 95
До релиза Firefox Quantum остаётся всё меньше времени. Он принесёт множество улучшений в производительности, в том числе сверхбыстрый движок CSS, который мы позаимствовали у Servo.
На хабре есть перевод "Внутри супер-быстрого CSS-движка: Quantum CSS (aka Stylo)" azymohliad
overdraw — это не банковский термин (превышение лимита), а композиция двух слов over и draw, т.е перекрашивание
You're right!
Разве перекрашивание будет не repaint?
Repaint — это когда состояние объекта изменилось и его нужно заново отрисовать.
Overdraw — это когда пиксели приходится закрашивать повторно, потому что один объект перекрывает другой.
Overdraw — это когда пиксели приходится закрашивать повторно, потому что один объект перекрывает другой.
слово «перекрашивание» может быть в двух значениях. одно «перекрашивание» — это красить слишком много (overdraw), а второе «перекрашивание» — это нарисовать заново (repaint)
Наверно его с overdraft перепутали
а как включить?
- gfx.webrender.enabled = true
- gfx.webrendest.enabled = true
- gfx.webrender.layers-free = true
- gfx.webrender.blob-images = true
- если Linux, layers.acceleration.force-enabled = true
Обновления пишут в блоге mozillagfx.wordpress.com.
Если только стабильную часть, то да, только gfx.webrender.enabled = true.
делал так же никаких 60 фпс не увидел
Включил стабильную часть на linux mint, про force-enabled не забыл, всё равно в about:support композитинг OpenGL. Стабильная лиса 62. ЧЯДНТ?
Предполагаю что вот этот флаг — gfx.webrender.enabled
Толково расписано. Было интересно почитать — что там внутри, и с какими сложностями сталкиваются. Внутренности — это всегда интересно)
Интересно, на сколько сильнее он теперь батарею жрать будет (при исп GPU бук начинает греться как ненормальный и сажать батарею на глазах). И насколько отжирать память GPU при использовании WebGL например.
В вашем ноутбуке два GPU. Совершенно не обязательно использовать «дискретный» GPU ради отрисовки 2d графики. Если всё окно занято WebGL-контекстом, то жрать память GPU не будет. Особо учитывая, что оная вообще не будет использоваться, но будет использоваться оперативка. Я могу быть немного не прав, но судя по всему в целом оно примерно так работает.
Я даже сначала обрадовался. Но нет, по прежнему одно встроенное. Дискретки стоят далеко не везде. И кстати да, я забыл, что жрать оно обычную оперативку будет на буке, т.к. там выделенной памяти для ускорителя нет.
Всё окно никогда (практически никогда) не бывает занято. Всегда что-то отрисовывается помимо GL, а часто и поверх него. Так что будет, никуда не денется.
Интересно, за что минусов так накидали?
Всё окно никогда (практически никогда) не бывает занято. Всегда что-то отрисовывается помимо GL, а часто и поверх него. Так что будет, никуда не денется.
Интересно, за что минусов так накидали?
Где-то тут говорится, что IGP скорее всего не будет ждать память GPU просто уже по той причине, что питается самой обычной RAM. Однако, что характерно, памяти должно выжираться меньше с WebRender. Или по крайней мере столько же. Ибо на слои память таки требуется. Но я не измерял.
Это говорит, что WebGL будет проще и быстрее. В относительно большой перспективе. Ещё там графики производительности в попугаях есть.
Интересно, на сколько
А на самом деле измерьте. На сколько попугаев стало лучше/хуже.
Питаться обычной RAM оно не может, т.к. GPU текстуры в RAM хранить не может. Для рендера они должны быть в его памяти, а гонять их каждый кадр накладно. А тем более выделять и освобождать её каждый кадр. Ну и само утверждение, что память GPU не используется и на CPU меньше — уже странно, т.к. где-то текстуры храниться должны.
Проще и быстрее — с этим никто не спорит. Вопрос конкретно в энергопотреблении. Кстати, что будет если GPU ему недоступен? Переключится на старый рендер или вообще не будет работать? WebGL периодически отваливается до перезапуска фоксы, а под линухом в какой-то момент вообще отвалился. Спец для шейдертоя приходилось оперу гонять пока он и там не отвалился почему-то :(
Проще и быстрее — с этим никто не спорит. Вопрос конкретно в энергопотреблении. Кстати, что будет если GPU ему недоступен? Переключится на старый рендер или вообще не будет работать? WebGL периодически отваливается до перезапуска фоксы, а под линухом в какой-то момент вообще отвалился. Спец для шейдертоя приходилось оперу гонять пока он и там не отвалился почему-то :(
Встроенный GPU (почти) никакой "своей" памяти не имеет — он хранит все текстуры в ОЗУ. Если вы под виндой сидите, посмотрите в параметры графического адаптера — там должна быть картинка вроде вот такой:
А что мешает GPU хранить текстуры в RAM?
Даже в не его выделенной RAM ничего не мешает, через PCIe оно прекрасно адресуется и пропускной способности более чем достаточно для рендера вебни.
Даже в не его выделенной RAM ничего не мешает, через PCIe оно прекрасно адресуется и пропускной способности более чем достаточно для рендера вебни.
Если честно, я не очень силён в данном вопросе. Не знаю как Vulcan, но OpenGl вроде не позволяет указывать, где их хранить. Через директ фокса вряд-ли работает. Решать это может только драйвер. С точки зрения производительности хранить их во внутренней памяти гораздо эффективнее. Она не только ближе, но и быстрее. Так что вряд-ли в обычной.
Картинки от Лин Кларк узнаваемые в любой статье) А за перевод спасибо.
Рисоваться будет быстро, а загружаться будет еще дольше чем сейчас?
Нет. Посмотрите видео. Например, вот это:
Это плохое, негодное сравнение.
Можно заметить, что для некоторых сайтов, например search.yahoo.com, выдается разная верстка (хорошо заметно по картинкам справа, плюс разные результаты поиска). Больше всего меня повеселило сравнение Google login: в FF нет логотипов других сервисов, а в chrome они появляются последовательно. А что если это такая анимация? Но в сравнении замеры для chrome заканчиваются именно после того, как они закончат загружаться. Еще если я правильно понял, то тесты проводились на реальной сети, что тоже некорректно.
В идеале сравнение производительности должно проводиться с помощью записанных сайтов с помощью какого-нибудь web page replay, чтобы полностью исключить влияние сети и обеспечить проверку одинаковой версии страницы. Без этого при большом желании можно подогнать любые результаты.
Можно заметить, что для некоторых сайтов, например search.yahoo.com, выдается разная верстка (хорошо заметно по картинкам справа, плюс разные результаты поиска). Больше всего меня повеселило сравнение Google login: в FF нет логотипов других сервисов, а в chrome они появляются последовательно. А что если это такая анимация? Но в сравнении замеры для chrome заканчиваются именно после того, как они закончат загружаться. Еще если я правильно понял, то тесты проводились на реальной сети, что тоже некорректно.
В идеале сравнение производительности должно проводиться с помощью записанных сайтов с помощью какого-нибудь web page replay, чтобы полностью исключить влияние сети и обеспечить проверку одинаковой версии страницы. Без этого при большом желании можно подогнать любые результаты.
Дожили. Пропускная способность GPU 336Гб/с а текстовая страница открывается 10с.
Было бы здорово если рядом с FPS показывался еще и КПД.
Было бы здорово если рядом с FPS показывался еще и КПД.
Странно, что сравнивается скорость загрузки, а не плавность анимации. Ведь при загрузке большая часть времени тратится на IO.
А у Edge сколько FPS? У него реализован офигительно приятный и плавный скроллинг. Перепробовал кучу плагинов, но не удалось такого достичь в Chrome.
В целом когда работать действительно приятнее, когда у интерфейса нет лагов
В целом когда работать действительно приятнее, когда у интерфейса нет лагов
Edge так же как и Safari — платформозависимые броузеры, которые договорились с ОС. Хром и Лиса вынуждены играть по общим правилам.
Что мешает им договориться с каждой ОС по отдельности? Мне, к примеру, очень нравится подход Sublime Text: потроха тулкита представляют собой целиком платформозивисимый код, в отличие от того же VS Code (со слов автора). Да, много работы, зато открывается мгновенно, а не пару секунд, и всё ещё кроссплатформенно.
На каких-то плагинах в Chrome все-таки остановились? Можете упомянуть здесь?
Забавно как вначале "вы, наверное, не понимаете, что такое FPS" а потом дикий хардкор с подробностями отрисовки начинается :) Тот, кто правда не знал, что такое FPS, поседел бы.
Попробовал я включить stylo ещё с первой статейки, месяц назад, или где-то так. Так вот оно после загрузки страницы жуть как тормозит, на секунду замирает всё. Это раздажало. Выключил. Других изменений не заметил.
Да дело не в движке рендеринга. А в том, что разработчики всё никак не могут отвязать UI от парсинга страниц и выполнения JS.
Это совершенно не дело, когда на восьмиядерном процессоре в момент загрузки странички подлагивает переключение вкладок (переключаются не в момент нажатия, а через 0.3-0.5 сек примерно) или скроллинг в соседней вкладке.
Это совершенно не дело, когда на восьмиядерном процессоре в момент загрузки странички подлагивает переключение вкладок (переключаются не в момент нажатия, а через 0.3-0.5 сек примерно) или скроллинг в соседней вкладке.
Опять же в текущей бете (Firefox Quantum) стало с этим намного лучше. Прямо в разы.
У меня бывает и через 5 сек, причём оно не виснет а как будто ставит уже принятый клик по вкладке в какую-то очередь.
Firefox 56, где-то с 54 версии вкладка не тормозит весь браузер.
Если вкладка тормозит, то так же тормозят кнопки расширений, но ничего больше не тормозит и не зависает. С нетерпением жду firefox 57, жаль, что некоторые расширения отвалятся.(cookiemanager+ и downthemall)
Если вкладка тормозит, то так же тормозят кнопки расширений, но ничего больше не тормозит и не зависает. С нетерпением жду firefox 57, жаль, что некоторые расширения отвалятся.(cookiemanager+ и downthemall)
Сижу интереса ради на альфе 58.
Конфиг компа:
Конфиг компа:
Конфиг компа
nForce4, процессор 2 ядра 939 сокет, DDR400 в два канала, 4гиг оперативки (1*4 планки), видеокарта GTX260 (DirectX10), 64 бит Win7 и браузер.
Лиса работает очень быстро и плавно даже без веб-рендера. Но при условии, что включено Direct2D.
Так в about:support пишет следующее:
Многопроцессные окна 2/2 (Включены по умолчанию)
Stylo</b> true (включено по умолчанию)
Композитинг Direct3D 11 (Advanced Layers)
Асинхронное панорамирование/зум включён ввод колесиком; включён драг полосы прокрутки; клавиатура включена; автопрокрутка включена
WebGL 1 — Визуализатор драйвера Google Inc. — ANGLE (NVIDIA GeForce GTX 260 Direct3D11 vs_4_0 ps_4_0)
Direct2D true
Прорисовка вне основного потока активирована true
DirectWrite</i> true (6.2.9200.16492)
AzureCanvasBackend Direct2D 1.1
AzureContentBackend Direct2D 1.1
ADVANCED_LAYERS available by user: Enabled for Windows 7 via user-preference
+ Аппаратное ускорение видео H.264 (этот пункт почему-то пропал из about:support)
и не работающее
WEBRENDER opt-in by default: WebRender is an opt-in feature
NO_CONSTANT_BUFFER_OFFSETTING Unsupported by driver
Видеокартой обробатывается практически всё что можно. Ну разве что WebGL отвалился и на http://www.ro.me/ показывает зелёный экран.
Не совсем понятно, какие минимальные системные требования будут нужны для работы веб-рендера?
Так например, много графических адаптеров с поддержкой DirectX9, но и в них есть отличия, с поддержкой шейдеров 2 и 3 версий. Видеокарта с поддержкой только DirectX 10 в Firefox работает как с DirectX11 и т.д.
Лиса работает очень быстро и плавно даже без веб-рендера. Но при условии, что включено Direct2D.
Так в about:support пишет следующее:
Многопроцессные окна 2/2 (Включены по умолчанию)
Stylo</b> true (включено по умолчанию)
Композитинг Direct3D 11 (Advanced Layers)
Асинхронное панорамирование/зум включён ввод колесиком; включён драг полосы прокрутки; клавиатура включена; автопрокрутка включена
WebGL 1 — Визуализатор драйвера Google Inc. — ANGLE (NVIDIA GeForce GTX 260 Direct3D11 vs_4_0 ps_4_0)
Direct2D true
Прорисовка вне основного потока активирована true
DirectWrite</i> true (6.2.9200.16492)
AzureCanvasBackend Direct2D 1.1
AzureContentBackend Direct2D 1.1
ADVANCED_LAYERS available by user: Enabled for Windows 7 via user-preference
+ Аппаратное ускорение видео H.264 (этот пункт почему-то пропал из about:support)
и не работающее
WEBRENDER opt-in by default: WebRender is an opt-in feature
NO_CONSTANT_BUFFER_OFFSETTING Unsupported by driver
Видеокартой обробатывается практически всё что можно. Ну разве что WebGL отвалился и на http://www.ro.me/ показывает зелёный экран.
Не совсем понятно, какие минимальные системные требования будут нужны для работы веб-рендера?
Так например, много графических адаптеров с поддержкой DirectX9, но и в них есть отличия, с поддержкой шейдеров 2 и 3 версий. Видеокарта с поддержкой только DirectX 10 в Firefox работает как с DirectX11 и т.д.
Ну я конечно понимаю что ночной билд, но пока я такую цену платить не хочу:
А я — такую (картинка из гугла, но мысль ясна)
Интересные технологии… Но что касаемо рендера текста, который (как я понял) переводится в текстуру, типа, не меняется и не анимируется при просмотре страницы, у меня родился вопрос: А как поведёт себя браузер на смартфоне, когда включен автоповорот, и размеры экрана стали другими, ширина объектов с текстом изменилась, текст весь сдвигается и т.д.?
Ведь если он (текст) был в виде текстуры, то при повороте нужно будет их все пересоздавать заново, а это заметные тормоза (особенно на мобильных устройствах). Они и сейчас почти на всех устройствах заметны при повороте, а не будет ли ещё хуже?
Ведь если он (текст) был в виде текстуры, то при повороте нужно будет их все пересоздавать заново, а это заметные тормоза (особенно на мобильных устройствах). Они и сейчас почти на всех устройствах заметны при повороте, а не будет ли ещё хуже?
Хорошая статья, для домохозяек. Особенно понравилось про использование GPU как игрового движка.
А курсор будет проваливаться сквозь уровень и застревать в кустах?
Вот бы еще подвисать перестал, а то периодически его даже прибить не получается.
Как-то так сложилось, что я не фанат Firefox (из лагеря Opera), но очень радуют такие новости про оптимизацию движка, который не Blink! Все-таки необходима в этой сфере конкуренция, да простят меня фронтенд-разработчики.
Вы только взгляните на рендеринг шрифта i.imgur.com/CjVYrwS.png
Ну, как бы, разработка еще не завершена. Он сейчас в Firefox в статусе alpha.
Данный скриншот, вероятно, сделан на ноутбуке, на котором матрица BGR, поэтому с мониторов RGB он сразу выглядит плохо. Но вообще да, рендеринг шрифтов в Firefox удручает. Для предотвращения замыливания можно отключить «аппаратное ускорение» и рендерер Skia.
Нет, на обычном ЖК мониторе гнусмаса. При старте браузера появляется громадное черное окно через секунду и сам браузер. По идее понятно что мозиловцы желают как лучше но блин. По сравнению с Edge, рендеринг видео занимает до 20% GPU против 4% у edge. Так еще и больше нагрузки тащут не оптимизированной.
В данный момент Webrender прикручен, что называется, по быстрому. Полная интеграция еще не завершена. И именно про видео есть баг/не реализованная фича — github.com/servo/webrender/issues/1645
При разработке WebRender мы поставили задачу, чтобы все приложения работали на 60 кадрах в секунду (FPS) или лучше, независимо от размера дисплея или от размера анимации. И это сработало. Страницы, которые пыхтят на 15 FPS в Chrome или нынешнем Firefox, летают на 60 FPS при запуске WebRender.
Это же явный подлог. Начиная с того, что какой-то отдельный бенчмарк — это явно не «все приложения».
В остальном. Мой chromium выдаёт так же 60фпс и я не знаю откуда взялись эти 15. Это явное враньё. Далее, я скачал это серво и запустил. Получил 60фпс(поверим, что это реальные), при этом я так же получил
1) артефакты, которые(на первый взгляд) так же видны на видео, которое ОЧЕНЬ хренового качества, почему? Совпадение?
2) нагрузка на цпу идентична хромиуму, а вот нагрузка на гпу выше.
3) У серво мало того, что артефакты, так ещё и визуальное качество рендеринга явно хуже.
4) Добавление банального box-shadow ломает полностью серво и все эти 60фпс пропадают.
5) Да что там box-shadow — даже банальное opacity уже не даёт 60фпс, а в хромиуме ничего не меняется и те же 60фпс.
6) графики в --debug wr-stats — врут. Я добавил банальный подсчёт максимального времени кадра на базе разницы между вызовами raf и что серво, что хромиум просаживаются до 30мс( в моём случае). Чего в графиках, конечно же, нет.
В конечном итоге, что мы имеем? Да ничего мы не имеем.
4,5) Есть известные баги на эту тему в webrender.
6) wr-stats учитывает только время отрисовки кадра(ибо это рендер, он про внешние запросы ничего не знает). Накладные расходы на обвязку и js сюда не входят, естественно. С точки зрения пользователя вы правы. Но сам процесс отрисовки в webrender во многих случаях значительно быстрее, чем без него, что открывает возможности для дальнейших оптимизаций.
В общем, вы пессимистично настроены. Вероятно вы во многом правы, но технология еще сырая и после сглаживания всех шероховатостей может привести к значительному росту производительности браузера в целом.
6) wr-stats учитывает только время отрисовки кадра(ибо это рендер, он про внешние запросы ничего не знает). Накладные расходы на обвязку и js сюда не входят, естественно. С точки зрения пользователя вы правы. Но сам процесс отрисовки в webrender во многих случаях значительно быстрее, чем без него, что открывает возможности для дальнейших оптимизаций.
В общем, вы пессимистично настроены. Вероятно вы во многом правы, но технология еще сырая и после сглаживания всех шероховатостей может привести к значительному росту производительности браузера в целом.
4,5) Есть известные баги на эту тему в webrender.
Ну какие же это баги. 90% недоработка является багом? Голословные утверждения являются багом? Это лишь то, что я за пару минут проверил. То, что мне первое пришло в голову. И это самое простое.
6) wr-stats учитывает только время отрисовки кадра(ибо это рендер, он про внешние запросы ничего не знает).
Это не накладные расходы. raf вызывается перед рендерингом кадра и если он вызывается через х2 после предыдущего — это явная просадка.
Но сам процесс отрисовки в webrender во многих случаях значительно быстрее, чем без него, что открывает возможности для дальнейших оптимизаций.
Это манипуляции. Там написано не «он кое как работает и быстрее нашего дефолтного, тормазного, рендеринга в firefox», а «в хроме 15фпс, у нас 60фпс — самый быстрый».
Если вы претендуете на оптимизацию аутсайдера, то это не дает вас быстрым. Если вы претендуете на «быстро» — сравнивайте с быстрыми. А именно с хромом.
А так это маркетинговый булшит уровня «самый шоколадный* *из всех наших продуктов» и что он делает тут — не ясно.
По поводу случаев. Их пока нет, либо по крайней мере я их не видел. Я вижу только подтасовку и пустые заявления.
В общем, вы пессимистично настроены. Вероятно вы во многом правы, но технология еще сырая и после сглаживания всех шероховатостей может привести к значительному росту производительности браузера в целом.
Понимаете в чём штука. Зачем заниматься подобными манипуляциями, если у нас что-то действительно есть? Зачем всё это про «самый быстрый/быстрый» и прочее? Почему не «возможно потом что-то да будет». Я не вижу этого — я вижу заявления, которые не соответствуют действительно.
Мне не нравится когда меня обманывают и считают за идиота. Я таким проектам не верю, таким людям не верю. И это правильно. И это не первое проявление.
Я могу рассказать краткую историю этого «движка». Вначале была параллельность. Мы придумали новый язык, который на это заточен и это должен был быть супер-параллельный движок. Потом как-то всё заглохло и вся параллельность превратилось в заспавн тысяч тредов и зависание через пару минут работы. Между тем в хромиуме есть многопоточный рендеринг и что-то я не вижу подобной желтухи и громких заявлений. И он есть и он работает.
Сейчас я вижу новую историю. Производительность с цпу мы не получили — теперь у нас новая идея — получить её с гпу. При этом казалось бы — причём тут раст, но вот так вот. И все эти рассуждения про «принципиально новое» — действительно. Верю. В гугле работают идиоты и до таких «инновационных» решений не доросли. При этом ладно, раньше было объяснение про «на расте проще писать многопоточные программы — поэтому мы даём фору хрому», но сейчас это не работает.
И естественно с «гпу» у нас работает 2-3% css, но мы уже всех побеждаем. Мы специально подбиваем под нас бенчмарки( которые на самом деле не бенчмарки, а фейк). Это не баги. Это подтасовка. Почему автор бенчмарка не написал там opacity? Знал что оно показывает 30фпс? Почему в видео специально зарезано качество? Чтобы люди не видели артефактов и качества рендера? Почему в видео содержится деза про 15фпс? В надежде что читатель не проверит?
И разве где-то в тексте это написано? Нет, это умалчивается. Опять же — мне не нравиться то, когда меня считают за идиота. Т.е. вам это нравиться и вы согласны с тем, что те, кто играют в подобные игры вам дадут хороший продукт?
Да и с технической части статья желтушная на 95%. Как будет у меня время я разберу её поподробнее. Возможно, кого-то это спасёт от слепой веры.
В любом случае. Тут плохо даже не всё это — тут плохо то, что подобное вгоняет комьюнити данного языка в средневековье. У нас везде победы, всё это враньё и желтуха затмевает нам разум. Всё это развивается в в сторону полного неадеквата семимильными шагами. И это плохо.
Примеры не заставляют себе долго ждать. Мои полностью объективные замечания минусуют. Хотя казалось бы — там нет ничего с чем можно соглашаться, либо не соглашаться. Там факты из реального мира. Отрицание этого — отрицание реальности. Именно в этом проблема.
90% недоработка является багом?
«гпу» у нас работает 2-3% css
Объективные цифры с потолка? Есть какие-то более предметные оценки, ссылки, аргументация?
raf вызывается перед рендерингом кадра и если он вызывается через х2 после предыдущего — это явная просадка.
Просадка в FPS анимации, но не обязательно проблема в рендере. Рендер может быть за 1 мс всё отрисовал, а еще 29 пришлось на другие участки кода между вызовами. Точных цифр не знаю, но до 50% вне рендера допускаю.
Это манипуляции. Там написано не «он кое как работает и быстрее нашего дефолтного, тормазного, рендеринга в firefox», а «в хроме 15фпс, у нас 60фпс — самый быстрый».
Да, в тех условиях самый быстрый. Или вы с этим тоже спорите? Это признак гордости, демонстрация потенциала. Не нравится формулировка — ваше право. Мне тоже не совсем нравится.
Я могу рассказать краткую историю этого «движка». Вначале была параллельность. Мы придумали новый язык, который на это заточен и это должен был быть супер-параллельный движок. Потом как-то всё заглохло и вся параллельность превратилось в заспавн тысяч тредов и зависание через пару минут работы.
Движок собственно Servo очень даже параллельный. И более менее допиленные части весьма быстры. Откуда информация про тысячи нитей, пару минут работы, что всё заглохло?
Почему автор бенчмарка не написал там opacity? Знал что оно показывает 30фпс?
Если бы вы знали историю WebRender, то знали бы, что этот бенчмарк довольно старый, простой и создан специально для проверки потенциала нового движка. Когда еще WebRender был на уровне «прототип для проверки концепции». С тех пор многое изменилось. Но бенчмарк остался показательным.
Сейчас я вижу новую историю. Производительность с цпу мы не получили — теперь у нас новая идея — получить её с гпу. При этом казалось бы — причём тут раст, но вот так вот. И все эти рассуждения про «принципиально новое» — действительно. Верю. В гугле работают идиоты и до таких «инновационных» решений не доросли. При этом ладно, раньше было объяснение про «на расте проще писать многопоточные программы — поэтому мы даём фору хрому», но сейчас это не работает.
Производительность тех частей, что остались на CPU получили. Stylo тому пример. На Rust кстати, да. Рендер было решено попробовать вынести с CPU на GPU, поскольку многие сценарии a) CPU-bound b) GPU делает многие вещи в рамках рендера быстрее. (Кстати пилится прототип растеризатора шрифтов на GPU).
При чём тут Rust — данные для GPU надо еще подготовить, очевидно же. И желательно параллельно в несколько потоков.
Да и с технической части статья желтушная на 95%.
Она не желтушная, она рекламно-айтишно-популярная. Ключавые особенности простыми словами. Упрощённо. Сознательно упрощённо. Если нужны технические статьи — есть технические блоги.
В любом случае. Тут плохо даже не всё это — тут плохо то, что подобное вгоняет комьюнити данного языка в средневековье. У нас везде победы, всё это враньё и желтуха затмевает нам разум. Всё это развивается в в сторону полного неадеквата семимильными шагами. И это плохо.
Победы есть, есть неудачи. Просто про них меньше пишут, но пишут. Всё враньё — так уж и всё? Что именно вы считаете полным неадекватом?
Мои полностью объективные замечания минусуют.
Не смотря на во многом верность ваших замечаний, факты тоже верны, но вот их интерпретация очень безапелляционная(помните, «полностью объективные»), слегка однобокая (и из-за этого недостаточно аргументированая). Не соглашаются именно с подачей и интерпретацией, как мне кажется.
P.S. я ни плюсов ни минисов ставить не могу по объективным техническим причинам, так что минисовал не я.
P.P.S. видите дату 3 мар. 2016 на видео демо? Это просто демонстрация возможностей раннего прототипа, а не коммерческие материалы. И Хром там той давности. Там и было 15 fps.
Я правильно понимаю, что на расте только css-движок написан в Quantum?
Полный список внедрённых и планируемых компонентов на Rust: wiki.mozilla.org/Oxidation#Rust_components_in_Firefox
Круто, конечно.
Но не стоит всех отломанных расширений. Буду сидеть на постепенно разваливающемся 54, что дальше — не знаю.
Но не стоит всех отломанных расширений. Буду сидеть на постепенно разваливающемся 54, что дальше — не знаю.
Эх, все зло и тормоза от Альфы. Каких только технологий не придумали чтобы сделать жизнь чуть чуть лучше, но до победы далеко.
А самое главное, что любая полупрозрачность (текст) требует активного режима смешивания который просто сразу в два раза все просаживает.
В свое время пытался рендерить различные сущьности в отдельные текстуры, чтобы потом в шейдере сразу все склеить. TMU сейчас ой как много.
От сюда и вопрос — а как ФФ склеивает слои? glBlend не предлагать.
А самое главное, что любая полупрозрачность (текст) требует активного режима смешивания который просто сразу в два раза все просаживает.
В свое время пытался рендерить различные сущьности в отдельные текстуры, чтобы потом в шейдере сразу все склеить. TMU сейчас ой как много.
От сюда и вопрос — а как ФФ склеивает слои? glBlend не предлагать.
Вообще ни какой разницы не заметил
хм… статья о том что теперь нужна обязательно суперМОЩная видео карта для того чтобы просто смотреть веб страничку?
Ура товарищи. Теперь FireFox будтет плавно тормозить без рывков.
Интересно, кэшируются ли пиксели каждого слоя.
Sign up to leave a comment.
Весь веб на 60+ FPS: как новый рендерер в Firefox избавился от рывков и подтормаживаний