Комментарии 35
В результате, при отладке wasm-кода, полученного, например, из C++, можно будет видеть исходный код, устанавливать в нём точки останова. По крайней мере, такова цель внедрения карт кода в wasm.
У нас отладочный бинарник занимает в районе 1Gb, боюсь да же представить, как это будет в браузере.
Точно так же как и ОС. Помечать блоки освобожденными/незанятыми и кидать ошибку.
Да. А тут у нас linear memory. Выделили вектор на mem_size и в нем живем.
Кроме того, функции используют не указатели, а целочисленные смещения.
Specify and implement incrementally:
a Minimum Viable Product (MVP) for the standard with roughly the same functionality as asm.js, primarily aimed at C/C++;
additional features :unicorn:, initially focused on key features like threads, zero cost exceptions, and SIMD, follow by additional features prioritized by feedback and experience, including support for languages other than C/C++.
Зачем для этого сборщик мусора, непонятно.
Например, если речь идёт о работе с DOM или об использовании API платформы, на которой выполняется код, у JavaScript пока нет альтернативы, так как эти API доступны из JS-программ напрямую, без добавления дополнительных уровней абстракции.
В связи с чем, у меня, лично, есть опасения, что по мере того как данная технология будет все больше и больше развиваться и становится более зрелой и самостоятельной, ее может постигнуть таже незавидная учесть, что и мультимедиа в HTML5 — фрагментация, урезание API и т.д.
Кто что думает на сей счет, очень интересно мнение сочувствующих?
Люди договариваются о стандартах, браузеры постепенно внедряют.И «лепят» несколько протоколов для показа видео через Web, похожие друг на друга как близнецы братья и ничем, принципиально, не отличающихся друг от друга.
Но это долгий и сложный процесс, и тут много подводных камней, от вопросов лицензий на кодеки (дорого)По кодекам они никогда не договорятся, так как V 8-9 бесплатны, а H264 поддерживается аппаратно на мобилках. Вся проблема в деньгах. А сейчас пытаются пропихнуть H265, который нужен, чисто, для смены поколений оборудования и программного обеспечения — опять же большие деньги.
(браузеры не хотят внедрять заведомо тормозные или энергоёмкие вещи)И поэтому используют javascript, DOM, css и т.д. Очень не убедительно получается. Если бы они реально хотели бы скорости и экономии, то использовали бы WA и API браузера — напрямую. Ну ведь честно, все эти вещи жрут память, такты, ресурсы — по сравнению с нативным кодом скомпилированным в WA, результат будет прямо противоположным.
Касательно ваших вопросов: так в том-то и дело, что в HTML5 все тоже самое, но вот только во Flash, хотя бы, все было унифицировано и одинаково на всех платформах где он поддерживался.
WA всего лишь дополнение к JS а не его замена, посмотрите пример использования, внимание его загружают с помощью JS. WA не имеет доступа к API браузера, да в принципе доступа к чему либо извне, этакий сферический конь в абстрактном вакуме
Не хочу вас расстраивать, но Unity помещает в WA только математику, все остальное управление игрой происходит в JS от отрисовки до управления игровыми событиями. Так что это только доказывает, что это конь в вакуме
Для такого нужно уметь нажать F12 в хроме
не только, но да
WA всего лишь дополнение к JS а не его замена, посмотрите пример использования, внимание его загружают с помощью JS. WA не имеет доступа к API браузера, да в принципе доступа к чему либо извне, этакий сферический конь в абстрактном вакуме
т.е. вы считаете что пробросив JS функцию в контекст WA вы изменили суть моего утверждения? =) GL.createContext это обертка создания контекста web gl на JS. т.е. вызывая функцию внутри другого контекста вы все равно вызываете JS функцию и тем самым инициализируете редерер. Методы отрисовки опять же реализованы на JS, события тоже на JS. Сборка по прежнему вызывает JS функции, которые работают так же как если бы их вызывали из JS, но не забывайте что при смене контекста теряется производительность. Так что это конь в вакуме да еще и без своих ног =)
Как работает JS: особенности и сфера применения WebAssembly