Comments 49
Самый простой вариант: за счет трамплина.
Первой инструкцией неоптимизированной функции будет переход на следующую инструкцию.
Для замены на оптимизированную версию достаточно поменять адрес перехода.
А в Chrome есть что-то подобное? И та крутая технология рендеринга, которую добавили в FF недавно — в Chrome что-то предвидится из того же ряда?
Да в общем-то альтернатива уже есть — AssemblyScript(более строго типизированный TypeScript), который компилируется в WASM.
Да, совсем с полпинка перекомпилить код действующего TS-проекта в WASM-код не выйдет, но в перспективе это проще, чем, например, переписать все на Swift | C++ | Python | etc.
Ну что Вы говорите такое?
Во-первых, язык сам по себе не может быть bottle neck, т.к. это всего лишь синтаксис и в таком случае bottle neck — это разработчик который не знает языка.
Во-вторых WASM пока (возможно никогда) не способен заменить JS т.к. он не имеет доступа к API браузера да и вообще ни к чему. Что бы WASM что-то делал кроме сложения чисел в него пробрасывают контекст (объект с набором функций написанных на JS которые взаимодействуют с API брвузера) собственно что и делает unity. Так что WASM — это не альтернатива, а дополнение к JS.
Ну и в-третьих про "все переписать заново" уже не мало статей написано и граблей истоптано. Не стоит оно того. Лучше приложить усилия для создания чего-то лучшего.
Уверены, что сможете сделать это быстрее и лучше, при этом соблюдая все те же требования? То есть: возможность копирования текстовых блоков, относительные размеры, чтобы на больших и маленьких экранах хорошо смотрелось и остальные возможности CSS?
Тем, кому эти требования действительно не нужны (браузерные игры, например), уже давно переползли на Canvas.
А как вы будете реализовывать tab-навигацию по полям ввода, нарисованным на сanvas, да при этом чтобы не медленнее, чем на JS, я не представляю.
Я, конечно, только теоретически себе это представляю — но есть мысль, что можно скомпилировать целый графический фреймворк (Qt/wxWidgets/nuklear/...) в WebAssembly, снабдив его бэкендом для вывода на canvas. Получатся обычные приложения. Не уверен по поводу скорости навигации по полям, но подозреваю что layout и отрисовка во многих фреймворках проще и шустрее чем махина DOM с CSS.
но подозреваю что layout и отрисовка во многих фреймворках проще и шустрее чем махина DOM с CSS.
Интересно, чем вызвано такое подозрение? Всё, что не содержит ни грамма JS — автоматически становится быстрее?
На том что оно, в отличие от HTML, никогда не разрабатывалось для того чтобы форматировать текст, быть может? Должна быть разница между деревом DOM с CSS, где какая-нибудь неосторожная вставка элемента в таблицу будет постоянно вызывать reflow документа, и фреймворком, который консервативно обновит только один виджет. (Я просто напомню, что речь вовсе не о JS, а об отрисовке приложения в canvas или родными средствами браузера. Вы вполне можете использовать emscripten чтобы скомпилировать этот фреймворк в JS, кто вам мешает.)
Итак:
- Пишем на canvas, на котором нельзя сказать "передвиньте линию X на N пикселей вниз", только полный repaint
- Фреймворк, быстрый за счет того, что умеет инкрементально обновлять картинку.
Не видите в этих друх пунктах противоречия?
Не вижу. Просто к сведению, рендерер браузера тоже не может обойтись без формирования кадра перед тем как он (обычно аппаратно) будет брошен на экран. Если фреймворк использует WebGL, то, грубо говоря, он использует те же самые примитивы, что и сам браузер, и доступ к оборудованию.
Реальные затраты, о которых я говорю, это разница между фреймворком дать виджету команду обновить свой вид — например, кнопке себя перерисовать, когда фреймворк даже не будет заморачиваться layout и обновлением, скажем, дисплей-листов других виджетов — и reflow (не repaint) в браузере, когда вы неосторожно изменяете шрифт на кнопке и в ответ рендерер перелопачивает DOM, заново определяет координаты и границы для всего, прозрачность и прочая, и прочая.
Да, вы можете приложить усилия и попытаться минимизировать количество чихов, на которые ваша страница делает reflow. Но я не уверен, что вы, верстая страницу, серьёзно на этом сосредотачиваетесь. Вы постоянно держите в голове, что событие hover (проводка мыши) может вызвать reflow? А простой ввод данных в текстовом поле? А просто запрос ширины элемента? И ещё много-много всего, о чём пишут статьи и руководства по чёрной магии для оптимизации рендеринга сайтов. Не запрашивайте ширину. Остерегайтесь добавлять/удалять элементы DOM из JS. Не ходите к броду на полнолуние… Но если вы всё это держите в голове, и это не вызывает дискомфорта, то я рад.
И ещё много-много всего, о чём пишут статьи и руководства по чёрной магии для оптимизации рендеринга сайтов.
Не надо утрировать, никакой черной магии здесь нет. Есть очевидное правило: не нужно изменять геометрию существующих блоков, чтобы не вызвать пересчета блоков, их окружающих.
Это правило следует из банальной геометрии и логики, которая работает как для декстопных layout-фреймворков, так и для браузерных. Какого-то особого преимущества, позволяющего десктопным решениям делать это быстрее, я не вижу.
Как это правило соотносится с :hover? Как соотносится со вводом текста в поле? Как соотносится с использованием анимаций из CSS3, где каждый кадр вызывает reflow? Как соотносится с чтением (sic!) свойств ширины/высоты элементов? Всё это не изменяет / не обязано изменять геометрию, если что.
Преимущество десктопных фреймворков в том, что они проектировались для разработки приложений, а не эволюционировали из языка разметки текста. Вам ниже domix32 правильно написал, DOM/CSS — это бутылочное горлышко веба. Для одних задач он подходит хорошо, для других, таких как приложения — хуже.
Как это правило соотносится с :hover? Как соотносится со вводом текста в поле Как соотносится с использованием анимаций из CSS3, где каждый кадр вызывает reflow?
До тех пор, пока эти события не вызывают изменения размеров блоков, все происходит быстро, анимации и интерфейс в целом остается плавным.
Как соотносится с чтением (sic!) свойств ширины/высоты элементов?
Опять же, значения размеров можно читать сколько угодно, если они не меняются по 10 раз в секунду.
Преимущество десктопных фреймворков в том, что они проектировались для разработки приложений
Декстопные декстопы и прилагательные приложения. А какие-то конкретные ноу-хау есть? Инкрементальная перерисовка не в счет, в это и браузеры умеют. Reflow, которым вы тут пугаете, не так страшен, как вам кажется.
Извините, но если выбирать между вашими совершенно неконкретными заверениями, что "в целом остаётся плавным" и "не так страшен как вам кажется" и массой статей (я даже не могу сказать сколько их вокруг) по борьбе с лишними reflow и обилием нюансов, и конкретными заверениями Мозиллы и Гугла о том что reflow таки страшен (а гугл вдобавок ещё и противоречит вам, говоря что он обычно проводится для всего документа а не инкрементально), то я скорее прислушаюсь к Гуглу и Мозилле.
Декстопные декстопы и прилагательные приложения.
Вы бы так свою область знали как вы ёрничать умеете. Раз такие пироги, то и спорить больше не о чем — верьте чему хотите, я пас.
Хорошая подборка источников, там рассказывается как бороться с некоторой проблемой. Но перед тем как лечить что-то, нужно точно поставить диагноз.
Возьмем, например, Хабрахабр, здесь справа есть кнопка обновления комментариев. Если на нее нажать, то произойдет перерисовка страницы, но ничего страшного не случится, система не затормозит, а вентиляторы не взвоют.
Нужно сначала убедиться в наличии проблемы, а потом уже можно искать материалы с руководством по исправлению.
Посмотрел в отладчике, никаких reflow не наблюдается. Для сравнения, reflow выглядит вот так, красные уголки у блоков — это момент, когда срабатывает forced reflow и просаживает fps.
Если использовать последню версию GL контекста, то если не ошибаюсь согласно поддерживаемому стандату OpenGL обновление линии будет происходить локально.
Интересно было бы посмотреть разницу между JS и WASM версиями quake в этом плане.
Ради формочки и табов можно поверх канваса ещё ноду показать. ЕМНИП ещё вроде можно повесить preventDefault() на обработчик и табать внутри канваса как заблагорассудится.
А вообще изначально шла речь о том что стандартный DOM является bottleneck и соственная реализация через какие-нибудь Scene Graph будут на порядок быстрее. Тем более что часть из обращений можно рассчитать на этапе компиляции.
реализация через какие-нибудь Scene Graph будут на порядок быстрее.
Если бы это действительно было так, то наверное крупные компании типа Facebook или Google уже бы выпустили свои подобные решения?
Единственное, что я видел в этом направлении, это PureQML, который рендерит QT-виджеты прямо в DOM.
Может быть, DOM не такой уж и медленный, как его принято в этом треде называть?
Выпускали и выпускают. Настольные приложения называются. guai упомянул мобильные, но и без ограничений мобильных платформ — если у компании есть приложение, и они хотят его шустрым, то они выпускают обычное настольное. (Да, у веба есть преимущество, это платформа, которая есть везде и которая не требует средств распространения/инсталляции — поэтому некоторые жрут кактус и героически сражаются с DOM, создавая офисные пакеты в вебе, но если вы думаете, что они получаются быстрее настольных...)
И все же: зачем свой велосипед, если нативная платформа нормально работает?
Давайте серьезно: вот эта самая дискуссия происходит на платформе с использованием обычного DOM, HTML, CSS и всё работает и не тормозит!
Хотя и на чистом css тоже не так давно шутер сделали. Правда не каждая машина осиливает отрисовку.
Или вовсе игры, в том числе и 3D.
… и мы возвращаемся к моему изначальному комменту. Да, есть варианты, где рисование на canvas дает преимущество. Там уже есть готовые движки, они конечно же выиграют от WebAssembly.
Но мнение, что "WebAssembly придет, все напишут свой DOM с блекджеком, а об обычном DOM все забудут", я не разделяю.
Михаэль Франц шлёт всем инноваторам горячий привет из поздних 80-х…
Ещё большее ускорение WebAssembly: новый потоковый и многоуровневый компилятор в Firefox