Firefox
Games and game consoles
WebAssembly
Comments 125
+2
Обновил Firefox до 52, но zen garden ругается, что требуется 52-я версия :(
0
Есть ощущения что линуховой версии это не касается.
0
Какой процессор? У меня на i5-6300U загрузка в районе 30% и всё ок.
0

model name: AMD Athlon(tm) II X2 280 Processor


01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 630] (rev a1)

0
Посмотрите в about:support строчку «Визуализатор WebGL2», должно быть написано «Google Inc. — ANGLE», иначе какие-нибудь ошибки, решение которых стоит поискать. Убедитесь, что эта опция включена: Настройки -> Дополнительные -> По возможности использовать аппаратное ускорение.

Кстати, ошибка InvalidStateError — попытка запустить в приватном просмотре, нужен обычный.
+2
Кстати, ошибка InvalidStateError — попытка запустить в приватном просмотре, нужен обычный.
что!?
это с какого фига веб приложение вообще зависит от способа сохранения приватных данных локально?
+1
Это из-за IndexedDB (MDN) — API для хранения данных/файлов, который работает в приватном режиме только в десктопном Chrome. Похоже, для этого необходимо хранение данных в ОЗУ и кто-то пытается реализовать это в Firefox: Bug 781982.
0
У меня тоже не работало сначала, но вот это помогло:
откройте about:config, параметер javascript.options.wasm должен быть true.
0
У меня линуксовая версия Firefox 64 bit, в zen garden всё скачалось и скомпилировалось, поставило три галки и потом написало:
QuotaExceededError
TypeError: eventHandler.target is null
0
Видимо где-то лимит на использование памяти прописан маленький.

У меня тоже сначала вообще не заработало (тоже как и у SLY_G писало что старая версия браузера, хотя стоит 52 и пишет что доступных обновлений нет).
Вручную включил выставив javascript.options.wasm = true

Тогда стало загружаться, но на этапе компиляции (кстати хоть тут нормальная многопоточность — все 4 ядра работали) закончилось ошибкой
WebAssembly instantiation failed:
out of memory

Хотя в диспетчере задач смотрел — на пике браузер 1.5 Гб памяти использовал, т.е. это не общая нехватка, а где-то еще лимиты прописаны.
0
Чем-то напоминает Silverlight, который из себя представлял библиотеку, которая выполнялась в браузере как обычное приложение и предоставляла для js кода доступ к своим переменным и т.п.
0
Почему представлял? Он до сих пор жив, игрушки на нём работают, например. В современной лисе его нет, но это же его не убило сразу
+2

На минуточку, его доустанавливать надо было). И, если память не врет, не было возможности его использовать в Linux без бубна. С бубном получалось, но не у всех.

+5
Вся проблема с silverlight состояла в том, что это не была часть существующего web'а. Это плагин, прямой конкурент флеша. Автор не сделал его под meego, maemo, tizen, foobaros, windows phone, ios, android, linux, windows, symbian, etc — всё, нет кросс-платформенности. А в браузере оно будет всюду. На всех платформах, которые могут показать браузер.

А открытый стандарт подразумевает, что это может сделать кто хочет, а не конкретный вендор, который «не хочет».
-1
Наконец-то, свою долю популярности получат всякие хромОСы и другие.
0
В отличие от других подходов типа Flash, которые требуют установки плагина в браузере..

А технологию Flash нельзя как-то встроить в браузер?
Всё резиновое, AS3 полноценный язык, игры 3D, анимация, видео, отображается везде одинаково и т.д.
+4
А технологию Flash нельзя как-то встроить в браузер?

Нельзя, ибо собственность одной корпорации, а не открытый стандарт.

0
Я думаю сама корпорация очень хотела-бы, чтобы встроили. Только владельцы браузеров не хотя. И правильно делают
0
Очень на это похоже. Убили fireworks, часть функций пытаются перетащить в фотошоп, теперь вот пилят XD.
UFO landed and left these words here
0
Ага и это прекрасно.
По мне так технология Flash очень крутая, круче чем WebAssembly в разы. Очень жаль что Adobe не может договориться со всеми платформами или отпустить технологию в open source.
UFO landed and left these words here
+1
Но Adobe Flash это пока отдельное нативное приложение как ни крути.
А веб-разработчики хотят полностью контролировать что происходит у них на странице.
Так же эта технология тащит за собой кучу проблем: Браузер не может контролировать чужой процесс. Многие баннеры сделанные на скорую руку, с утечками памяти. Cookies у flash свои. Новые дыры исправляются не синхронно, то есть браузер уже знает что есть важная дыра в безопасности, а Adobe еще только исправляет ее. Что в таком случае делать браузеру?

Вот если бы этот формат сделали открытым, можно было бы полноценно внедрить Adobe Flash в браузер, чтоб прямо из JS можно было обращаться к функциям Flash. А разработчики браузера сами бы имели возможность оперативно закрывать баги, до выхода официальных исправлений.

Сегодняшнее положение Adobe Flash скорее выглядит как «Не себе, не людям». Возможно Adobe еще верит в Apollo, где технологию Flash можно будет применять для создания Desktop приложений, но этот проект скорее мертв, чем жив.
0
Спасибо за подробное пояснение.
Мне тоже хотелось бы чтобы это был открытый формат и надеюсь так и произойдет.
0
В Хром же вроде он давно внедрен. Отдельного процесса для флеша не запускается. А обновляется он вместе с браузером, а не как отдельное приложение/плагин как в FireFox или I.E.
+1
Почему вы так решили? И отдельный процесс у него есть (причем хром создает еще один, что бы весь браузер не упал в случае ошибки). И установлен он как плагин.

А вот и доказательства.



0
Хм, похоже был не прав. Значит он просто поставляется и обновляется вместе с браузером вместо того, чтобы использовать установленный в системе как делает FireFox или старая опера. Но по сути такой же плагин.

При обновлении флеша с get.adobe.com флеш для FireFox и других браузеров обновляется (и хранится он в одной из папок винды), а для Хрома нет — в хроме при проверке другая версия и загружаемая из другой папки. Зато хром сам его обновляет отдельно от установленного в системе.
0
Я не очень понимаю зачем и кому оно надо?
САПР в браузере? Перемалывать в браузере числа? Но ведь он не для этого делался. Браузер ж скорее тонкий клиент, все вычисления к серверу. Если нужно мгновенное включение, без установки, то почему бы не сделать отдельно экзешник портабельной версии, который по тому же http будет получать ресурсы? К тому же и пошустрее будут из нативного кода то, а не промежуточного. Даже для вебщиков вроде не должно быть проблем, сейчас же активно js под десктоп развивается.
Ну а игрушки в браузере — простые итак работают, сложным не место в браузере(да и простым в принципе тоже).
«Переиспользование нативного кода»? Да ведь его итак придется дорабатывать нехило+и раньше работало на asm.js, причем говорят пошустрее.
Зачем развивать новую технологию, заполнять браузер лишними мегабайтами еще одной ерунды, которая делает из хлеба троллейбус, да потом еще и поддерживать? Разве что гуглу хромбуки попиарить и ФФ с хромом за собой пользователей застолбить, ведь сторонним браузерам все тяжелее будет гнаться за монополистами.
+2
Браузер ж скорее тонкий клиент, все вычисления к серверу.

Хомячков много, серверов мало, если перенести часть вычислений на клиента, это разгрузит сервер и позволит делать больше интересных вещей.

+8
Чему место в браузере а чему нет решает индустрия и экономика, а не разглагольствования о волшебном правильном мире. Задача разработчиков браузеров, серверов и стандартов — удовлетворять требованиям индустрии и предлагать новые пути развития в экономике, чем технология WebAssembly, возможно, и станет (предыдущие как java или flash закрыты и зависимы от компаний, поэтому их судьба была лишь долгими страданиями).
+2
А чем вам не нравится САПР в браузере? Или, к примеру, фотошоп?

Тот же Adobe можно со временем перегнать свои творения в веб, что будет 100% защитой от крякания

Да и админам проще будет сервер с тем же САПРом поднять
А а кто может и кто не может пользоваться — настраивать в политиках, а не ставить каждому на комп
Даже удалённая установка — это время
+1
Как минимум, зависимостью от наличия Интернета и его качества. Программы такого уровня весят поболее страниц на пару сотен килобайт, а кто то до сих пор сидит на медленных каналах, типа adsl. Да и, я думаю, не особо удобно работать в одной вкладке, когда каждый пиксель пространства на счету, полноэкранный режим не вариант потому, что параллельно мне может быть нужно еще несколько программ или тот же браузер.
0
Наличие интернета (или локальной сети в случае использования в организации со своим сервантом и админом) обычно и так необходимо для общения с сервером лицензий

Ну а качество связи — нативный код думаю поменьше будет чем голый js, даже минимизированный
К тому же можно придумать варианты кэширования сборок

Правда, этим должны заняться не пользователи, а разработчики
И, думаю, лучше будет, если разработчики браузеров добавят фичи кэширования с настройками (например, запрет на автоматическое обновление кэша)
+1

Вряд ли wasm-бинарники будут меньше системных бинарников по объёму. Кроме того, в wasm не предусмотрено механизма разделяемых библиотек, т.е., другими словами, все приложения будут компилироваться статически. Далее, если поставлять всё приложение единой сборкой, то при обновлении придётся перекачивать много данных. Придётся как-то дробить на модули.


Опять же, серьёзные приложения типа фотошопов-кадов определённо будут весить много, и кеша браузера на всё не хватит. Это тоже будет кушать трафик как пользователя, так и разработчика.


Наконец, ресурсоёмкие приложения (тот же фотошоп) вынуждены создавать в системе свои файлы подкачки, иначе им не хватит памяти.


Кажется, что здесь может помочь некоторый новый API, позволяющий сайтам создавать на компьютере свои защищённые файловые хранилища. Ещё один шаг к браузеру-ОС :)

0
Ещё один шаг к браузеру-ОС

Вот! Чего бы не использовать уже существующую JVM, какую-нибудь.
Хоть в браузере, хоть вне его. Уже давно есть и изобретать ничего не надо.
0

Так как раз всякие джависты и дотнетчики кричат: "Не хотим писать на JS! Закапывайте его! Даёшь WebAssembly, чтобы мы могли компилять свои джавы для браузера!"

0
А уже же есть всякие Ява-апплеты. Что с ними не так?
0
Так и эта штука, я думаю, так сможет. =)
Можно было бы JVM с браузером таскать, например.
Все пишут, что этот wasm новая и крутая технология, но не покидает ощущение, что всё это уже было и было успешно закопано.
+1

Так с технологиями обычно и бывает. Вот кто сейчас вспомнит про VRML, например?

0
Они просто опередили время с этой технологий. В те времена 3д сайты никому не были нужны, а сейчас хоть очки с приемлемой картинкой появились.
+1
Есть же ещё кэширование приложения. Сейчас делаю небольшой сервис, он прекрасно работает, когда отключают интернет. Нужно получить данные с сервера?! Пару килобайт json'а осилит даже медленный интернет.
Зато все работает на всех платформах, и не нужно ставить отдельное приложение, в котором ты будешь работать от силы пару минут в неделю.
+6
Нравится оно или нет, но реальность такова, что современный браузер — уже не тонкий клиент, а исполняющая среда. Одни приложения в браузер выгружают безмозглую оболочку, другие выгружают вполне тяжёлый клиентский интерфейс и какую-то бизнес-логику.
Почему не нативные приложения? Потому что нужна универсальность. Пользователям нужно, чтобы «зайти по ссылке с любого устройства и работало», владельцам приложений нужно, чтобы не разрабатывать отдельное приложение под каждую платформу и чтобы пользователи были довольны.
И вот сейчас всё это реализовано на некоем кошмарном уровне, который до сих пор по удобству, функциональности и производительности (как для пользователей, так и для разработчиков) не дотягивает до уровня десктопных клиент-серверных приложений VB/Delphi середины 1990-х. Т.е., минуточку, того, что было достигнуто четверть века назад. Целую эпоху в мерках ИТ. На оборудовании, на порядки уступающем по производительности современным наручным часам. Пора с этим что-то делать :)
0

Что же мешало сделать всё это раньше на обычном JS и канвасе, завоевав рынок первым?

0

Для обычных интерфейсов канвасу и так хватает производительности. Просто разработчикам это не нужно.

UFO landed and left these words here
0
А зачем вам нужна строительная САПР в браузере? Тот же Компас вполне работает себе на зоопарке компов.
UFO landed and left these words here
+2
Если это все правда, то весь зоопарк файрволов и антивирусов начнет строчно учиться залезать прямо в браузеры, чтобы всю эту радость внутри браузера контролировать. В результате получится все то же самое, если не хуже.
UFO landed and left these words here
0
Ой, а то в браузерах дыр мало. А чем более развитая среда исполнения, тем удобнее эти дыры из неё эксплуатировать.
UFO landed and left these words here
0
Если мы хотим (мы не хотим, но тут про это пишут) фотошоп в браузере, то без доступа во вне никак не получится.
UFO landed and left these words here
0
Расскажите это касперскому, который Free.
Он уже встраивает свой сертификат в https трафик. Правда при этом установщик забыл добавить сертификат, которым это всё подписано, в доверенные корневые сертификаты.

Второй довод — в вики на оф сайте:
Как включить расширение Kaspersky Protection в браузерах Internet Explorer, Google Chrome, Mozilla Firefox
0
Снятие головной боли с установщиками, обновлениями, песочницами и переносимостью. Теперь это проблемы браузера.
-8
WebAssembly это наверное хорошо, но работать надо в другую сторону:
image

(проверку буфера обмена мы делаем и если там пусто, пункты меню неактивны. а вот с пустой формы вырезается и копируется вполне отлично)
+3
А теперь на нем пусть напишут флеш ) 100500 флеш-мувиков не должны кануть в лету! )
+2
Сделали же ещё в прошлом релизе, работает если руками включить и с ограниченным количеством плагинов
0
Там была многопроцессность. Если я правильно помню, то там идея в том чтобы каждую вкладку обрабатывать в отдельном процессе. От этого ограничение в 1 поток на рендер 1 вкладки не пропадёт. Для наглядного сравнение запустите html5 игру в лисе и в хроме, посмотрите на загрузку цпу и на фпс в игре.
+2
Очень интересно, как из WebAssembly происходит доступ к выводу графики
0

Судя по тому, что сейчас у WebAssembly ограниченный интерфейс взаимодействия с браузером, то пока что только через JS.

0
Отрисовать битмап какой-нибудь Skia и отправить байтмассивом в JS. А тот уже на канвасе нарисует.
+1
Ну а как по-вашему какой-нибудь GIMP работает? Отрисовывает битмап в памяти и отправляет байтмассивом оконной подсистеме.
-1
Я в общих чертах знаю, как работает Х11. Разве GIMP не использует никакой технологии ускорения вывода?
0
Так оно всё равно сводится к «нарисовать битмап в памяти и отправить в видеокарту»
UFO landed and left these words here
0

Никак, из webasm нету доступа ни к webgl, ни к webgl2. Там даже sin cos нет. Чтобы вызвать метод webgl надо вываливается в JS. Также нельзя там использовать ни WebGlTexture, ни WebGlProgram. Таким объектам надо присваивать индексы и хранить в JsArray. тянутся

+1
Скорее наоборот, теперь можно по сути написать низкоуровневый движок с api,
к которому можно достучаться через жс, учитывая скорость развития и появления
всевозможных фреймворков — это очень и очень здорово.
0
И что мешало использовать какие-нибудь ява-апплеты?
+2
А потом оно начнет в вэб-САПРе и фотошопе рекламу показывать на пол-экрана, потому что надо отбивать новую технологию.
После этого усталые парни с красными глазами в одинаковых корпоративных детских футболках нам объявят, что старые оси и слабое железо больше не поддерживаются новым супер-стандартом и всем надо сходить в магазин и купить новое, если в интернет хотим выходить.
И окончательно покончат с пиратским ПО — ведь они только ради этого всю эту затею пилят.
UFO landed and left these words here
0
Я не понимаю, что помешает скачать этот web-assembly, крякнуть и захостить локально на каком-нибудь IIS?
0
Проверка лицензий онлайн. Локально вы в нем скорее всего мало что запустите.
0
Подобные механизмы когда-то мешали взламывать ПО?
Скачают, сломают, и будут хостить локально.
0

Зависит от объёма серверной логики. Это может быть просто аутентификация и хранилище, а может и какая-то обработка. Условно, 3D-редактор может отправить сцену на рендер на ферме разработчика, а Фотошоп — попросить сервер сшить панораму.

0

Да, типа того. Но на текущий момент, фактически, через wasm можно сделать только числодробительные функции. Никакие API браузера и HTML-элементы из wasm сейчас недоступны.

0

Все верно. WebGL, WebAudio, Video, Network в WebAsm не доступны. Можно только складывать и умножать и писать в массив.

0

Нет не верно. Например из NDK можно вызвать функции OpenGL напрямую, а из webAsm нельзя вызывать. В webasm можно вызвать метод на JavaScript (вывалиться назад из Webasm в JS), а уже из JS вызывать webGl.

0
С каждым днем разработчики пытаются сделать из браузера полноценную ОС. Если ассембли взлетит то это будет прорыв на уровне AJAX
0
Это всё хорошо, но с 52-й версии Firefox требует PulseAudio. А поддержку ALSA можно получить только собрав самому, указав
ac_add_options --enable-alsa
0
Похоже, что от WebAssembly выигрывают только любители C++, т.к. пока нет никаких признаков того, чтоб в него компилировалось что-то другое — Python или Java, к примеру.
0
У меня одного последняя версия огненной лисы тормозит безбожно и память жрет как не в себя?
0
У меня сама лиса работает шустро, но вот именно эта демка из статьи работает с ужасно низким фреймрейтом (на глаз около 10fps) на вполне себе неплохой конфигурации.
0
Тормозит невыносимо, вкладки подвисают на несколько секунд, а то и минут
0
Это еще раньше началось с 49 по наклонной.

32 битная версия уже на 5-7 тяжелых вкладках умудряется в 2 Гб лимит упереться и либо полностью повеситься либо в лучшем случае тащиться как удав по стекловате до перезапуска.
На некоторых сайтах просто вешается, хотя 47я и более ранние версии этот же сайт отображают без проблем.

64 битная еще более менее нормально работает — жрет много по сравнению с более ранними, но хоть подобных критических косяков нет

Сидел на стабильной 47й версии, но тут разрабы начали руки выкручивать вынуждая обновляться — одни из нужных плагинов после очередного обновления в 47й версии полностью перестал работать, потом криворукие веб-админы SoundCloud в скриптах какую-то совместимость поломали, что 47я больше не может музыку воспроизводить, хотя раньше без проблем работала. Еще на паре сайтов косяки вылезать стали, которых раньше не было (видимо тоже у админа что-то «улучшить» и обновить руки слишком сильно чесались)
0
Решил освоить webassembly, полез в гугл, и знаете что? Будто вернулся во время ФИДО, модемов и всего этого самого. «Dark Ages», как говорит Страуструп. Более-менее вменяемая информация нашлась на MDN, но один из его CDN похоже лежит и некоторые ресурсы не грузятся. Почему так?
+1
Потому что wasm это лишь дальнейшее развитие идеи asm.js. Всё что работало для asm.js будет, на данный момент, работать для wasm

Поэтому ничего более сложного, чем уже есть на официальном сайте не требуется http://webassembly.org/getting-started/developers-guide/
0
Все-таки webassembly — это платформо-независимый язык, так что на вычислительных задачах с настоящим нативным кодом, использующим все преимущества конкретной архитектуры, ему трудно будет тягаться.
0
Там JIT работает, так что еще вопрос, когда продукт массовый, а не компилируется под конкретный процессор.
0
Теперь майнить биткоины, создавать ботнеты и брутфорсить пароли на компьютерах клиентов станет еще проще!

Даешь проприетарщину в клиентский код браузеров!
0
Что они сделали с рендером шрифтов в этой версии??? (Windows) Всё мутное. Что с Direct2D, что без, что вместе с MacType. Есть какие-нибудь настройки как вернуть всё обратно?
0

Решение:


gfx.canvas.azure.backends = direct2d1.1,cairo
gfx.content.azure.backends = direct2d1.1,cairo

(отключить там skia)


Ну и "аппаратное ускорение" отключать, само собой.

+1
Ура, наконец то! Теперь игры на Юнити и Unreal Engine можно будет просто конвертить в веб. Без плагинов!

Для тех кто в танке, тут основные плюсы такие,
* Не нужно компилировать — нужно только проверить wasm код в 25 раз быстрее запуск чем JS
* Ты точно знаешь с какой скоростью это будет работать
* меньший размер

Ждем теперь многопоточность и нативные вызовы GPU

Кстати теперь есть возможно писать в вебе код на С# — так как юнити конвертирует его в C++, а потом в wasm

0
меньший размер

Плагин Unity надо скачать и установить один раз, а с wasm весь рантайм будет закачиваться постоянно. Вы уверены, что получится меньше?

+1
Юнити плагин похоронен в месте с другими NPAPI, разговор именно про JS vs WASM
0
> Не нужно компилировать

Нужно, wasm — это AST.

> Ты точно знаешь с какой скоростью это будет работать

Не знаешь — у всех устройства разные.
+1
> Нужно, wasm — это AST.
его не нужно компилировать как JS. Там идет просто проверка и перегон в машинный код. Как я уже сказал, разница в 25 раз. Те если запустить большой проект — к примеру игру. То она секунд 10 просто переваривает JS а потом еще около минуты — его оптимизирует — на сколько я понимаю делает JIT.

wasm этого лешен, сами С++ компиляторы будут оптимизировать код — задача браузеров валидировать и исполнять.

> Не знаешь — у всех устройства разные.
То что время выполнения зависит от железа — ну это понятно.
Реч ведь о том, что JS может работать по разному на одинаковых машинах — в зависимости от того, где компилятор оптимизировал код, а где нет. Не говоря уже об разных компиляторах. У wasm такой проблемы нету, в разных браузерах, он будет работать всегда одинаково.
0

Строго говоря, у wasm тоже JIT. Его бинарный код не будет интерпретироваться. И это не нативный машинный код. Так что компиляция на стороне клиента всё-таки будет.Разумеется, это не должно занять много времени.

0
его не нужно компилировать как JS. Там идет просто проверка и перегон в машинный код. Как я уже сказал, разница в 25 раз. Те если запустить большой проект — к примеру игру. То она секунд 10 просто переваривает JS а потом еще около минуты — его оптимизирует — на сколько я понимаю делает JIT.

wasm этого лешен, сами С++ компиляторы будут оптимизировать код — задача браузеров валидировать и исполнять.

Да ну, вот же выше демка с садом — wasm делает все тоже самое. Сначала прежде чем запуститься долго комплит загружая все ядра процессора при этом.
0
Юнити давно умеет компилить в asm.js. Что, впрочем, не особо и помогает.
Only those users with full accounts are able to leave comments., please.