#javascript #performance #dom #game-engine #game-physics
#javascript #Производительность #dom #игровой движок #физика игры
Вопрос:
Я пытаюсь понять, почему браузерам сложно полностью отображать DOM много раз в секунду, как это делают игровые движки для своего canvas. Игровые движки могут выполнять множество вычислений для каждого кадра, вычисляя свет, тени, физику и т. Д., И при этом сохранять плавную частоту кадров. Почему браузеры не могут делать то же самое, позволяя полностью повторно отображать DOM много раз в секунду без проблем?
Я понимаю, что рендеринг DOM и рендеринг игровой сцены — две совершенно разные задачи, но я не понимаю, почему последнее намного сложнее с точки зрения производительности.
Пожалуйста, постарайтесь сосредоточиться на конкретных аспектах рендеринга DOM и объясните, почему игровые движки не сталкиваются с теми же проблемами. Например: «браузеры должны анализировать HTML, в то время как весь код игры предварительно скомпилирован и готов к запуску».
РЕДАКТИРОВАТЬ: я отредактировал свой вопрос, потому что он был помечен как самоуверенный. Я не спрашиваю здесь мнения, только факты. Я спрашиваю, почему браузеры не могут полностью повторно отображать DOM со скоростью 60 кадров в секунду, как игровые движки отображают свой холст. Я понимаю, что браузеры сталкиваются с более сложной задачей, но я не понимаю, почему именно. Пожалуйста, придерживайтесь только информативных ответов и избегайте мнений.
Комментарии:
1. Я не думаю, что DOM вообще медленный в современных браузерах, даже на мобильных устройствах.
2. Это абсурдное злоупотребление тем, для чего предназначен браузер.
3. @kundasaba DOM означает объектную модель документа . HTML расшифровывается как язык разметки гипертекста . Если вы попытаетесь изменить HTML-элементы с помощью DOM для рендеринга игры, у вас возникнут проблемы.
4. посмотрите здесь — это то, что делают игры — они загружают очень специфический код рендеринга в стиле c на видеокарту, карта выполняет все вычисления для рендеринга — это недоступно в браузере, поскольку у вас слишком высокий уровень — браузер должен перейти на более общий рендеринг (если вы не используете WebGL) opengl.org/archives/resources/code/samples/glut_examples /…
5. Короче говоря, сложные игры не используют DOM. Приложения с графическими нагрузками, например: игры в основном основаны на canvas и / или webgl. Вы должны прочитать о них, как они эффективно создают игры для браузеров.
Ответ №1:
Игры — это программы, написанные для выполнения специфичных для них операций — они написаны на языках низкого уровня asm / c / c или, по крайней мере, на языках, которые имеют доступ к операциям машинного уровня. Когда дело доходит до графики, игры могут загружать программы в графические карты для рендеринга: рисования векторов и раскрашивания / растеризации
https://en.wikipedia.org/wiki/OpenGL
они также оптимизировали память, использование процессора и ввод-вывод.
С другой стороны, браузеры — это приложения, к которым предъявляется много требований.
В первую очередь предназначен для рендеринга HTML-документов посредством создания объектов, представляющих html-элементы. Браузеры получили более сложную работу, поскольку они поддерживают несколько версий dom и типов документов (DTD) и связанную с ними безопасность, требуемую каждым DTD.
и должны поддерживать рендеринг очень общего набора документов — одна страница отличается от другой. Должны быть библиотеки для ввода-вывода, синтаксического анализа CSS, анализа изображений (JPEG, PNG, BMP и т. Д. …..), а также проигрыватели фильмов и связанные с ними кодеки, аудиоплееры и их кодеки, а также поддержка веб-камер. Кроме того, они поддерживают среду кода JavaScript (не только язык, но и ввод-вывод и обработку событий), а также исторически поддерживают COM, Java-апплеты.
Это делает их очень универсальными инструментами, но тяжеловесными — они несут много багажа.
Графические аспекты никогда не могут быть такими же производительными, как выделенная программа в этом аспекте, поскольку API, который они предоставляют для таких операций, всегда выполняется на более высоком уровне.
Даже API Canvas (как следует из названия) представляет собой уровень абстракции над библиотеками рендеринга более низкого уровня. и каждый уровень абстракции увеличивает производительность.
https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API
Для повышения производительности графики в браузерах теперь доступен новый стандарт call WebGL — хотя это все еще API и выполняется в изолированной среде — поэтому он все равно не будет таким производительным, как выделенный код
https://en.wikipedia.org/wiki/WebGL
Даже игры, использующие игровые движки: Unity, Unreal, будут получать доступ к графическим функциям, процессору, памяти и вводу-выводу гораздо более специализированным образом, чем браузеры, поскольку сами игровые движки предоставляют специальные функции рендеринга и растеризации, которые разработчик может использовать в своих играх для оптимизации графических функций.. Браузер не может, поскольку они должны охватывать множество общих случаев, но не конкретные требования.
Ответ №2:
Прежде всего, игры в Интернете не часто используют DOM. Они используют более быстрый Canvas API. DOM создан для изменения содержимого документа (это то, что обозначает D в DOM), поэтому он действительно плохо подходит для игр.
Как это возможно, что мой дерьмовый телефон может без проблем запускать Call Of Duty, но так сложно написать большую веб-страницу, которая будет работать на нем плавно?
У меня никогда не было проблем с производительностью с DOM. Конечно, если вы обновляете целое <body> одним .innerHTML назначением 60 раз в секунду, я не удивлюсь, если производительность будет плохой, потому что браузеру необходимо:
- Проанализируйте HTML и создайте дерево DOM;
- Примените стили и вычислите положение каждого элемента;
- Визуализируйте элементы.
Каждый из этих шагов требует много работы для процессора, и в большинстве браузеров процесс в основном однопоточный.
Вы можете улучшить производительность,:
- Никогда не использую
.innerHTML..innerHTMLзаставляет браузер преобразовывать HTML в дерево DOM и наоборот. Используйтеdocument.createElement()и.appendNode(). - Избегайте изменения DOM.По возможности измените только стили CSS.
Комментарии:
1. Но это именно мой вопрос — почему так сложно создать dom, который мог бы обновлять innerHTML 60 раз в секунду и оставаться быстрым, как игры.
2. Прежде всего, спасибо за ваш ответ и терпение 🙂 Но я уже знаю и понимаю все это, я сам веб-разработчик, чего я не понимаю, так это почему игровые движки не страдают от той же проблемы. когда вы ведете машину в игре, движок должен вычислять свет и тени множества частиц, и он делает это без проблем
3. Потому что игровым движкам не нужно анализировать какой-либо текстовый формат в структуру данных или вычислять стили для всех элементов так же, как это делает CSS. DOM не предназначен для производительности.
4. итак, вы говорите, что узким местом является синтаксический анализ текста и css?
5. @kundasaba Чтобы ответить на ваш вопрос
why is it so hard to create a dom that could be update the innerHTML, во-первых, «жесткий» и «медленный» здесь относительны. Все сводится к тому, насколько тяжелым является ваш DOM и как часто вы позволяете браузеру повторно отображать все. Существуют эффективные способы управления DOM, такие как пакетные обновления и интеллектуальные алгоритмы, которые используют современные веб-приложения. Но это все для веб-приложений; для игр это не сработает, поскольку это не документ, который вы визуализируете. Это графика, и она в основном основана на canvas api или webgl.
Ответ №3:
Как правило, это зависит от игры . самые мощные игры разрабатываются на C или C engine, поэтому они напрямую связаны с памятью и используют всю мощность процессора.
Вместо веб-страниц, основанных на DOM, они записываются с помощью интерпретируемого языка, такого как JavaScript. Кроме того, проблема может быть связана с сервером, если веб-страница развернута неправильно или на плохом медленном сервере .