Вышел Firefox 52 c поддержкой WebAssembly


    3D-рендеринг демки Zen Garden в браузере Firefox 52 c поддержкой WebAssembly

    Mozilla выпустила Firefox 52, последнюю версию браузера с поддержкой операционной системы Windows XP. Сделан ряд важных изменений: упрощено подключение к хотспотам, где нужно сначала залогиниться в браузере, появились предупреждения об опасности, если страница запрашивает пароль по небезопасносму соединению (не HTTPS), исчезла поддержка плагинов NPAPI (кроме Flash, а в билде ESR останется полная поддержка), закрыто 28 уязвимостей.

    Но ничто это не сравнится с главным и фундаментальным нововведением — поддержкой низкоуровневого языка программирования WebAssembly (wasm) типа ассемблера, который называют одной из самых значительных инноваций веб-платформы за последнее десятилетие. Это то, чего не хватало JavaScript.

    WebAssembly



    Разработчики объясняют, почему возникла необходимость в создании WebAssembly. Дело в том, что JavaScript был изначально задуман как легковесный язык для простеньких скриптов. Никто не предполагал, во что он разрастётся и как его начнут применять. Его придумали для новичков в программировании — для несложных вещей типа написать форму на веб-странице.

    С тех пор многое изменилось. Современные веб-приложения — это сложные компьютерные программы с клиентским и серверным кодом, большая часть которого написана на JavaScript. Несмотря на прогресс в развитии самого JavaScript и все попытки разработчиков создать эффективные движки для быстрого выполнения JavaScript, ничего не вышло, это просто физически невозможно. У JavaScript есть неотъемлемые ограничения. Браузер просто не может выполнять этот код хотя бы примерно так быстро, как нативный код в операционной системе.

    Mozilla первой созрела до разработки своеобразной виртуальной машины в браузере, где можно запускать низкоуровневый код — и несколько лет назад в качестве демонстрации выпустила asm.js (Google экспериментировала с Native Client API). Подъязык asm.js проявил себя настолько хорошо, что стало ясно: нужно объединять усилия со всеми крупнейшими компаниями-разработчиками для совместного проекта, который двинет веб вперёд.

    Низкоуровневый язык WebAssembly может работать в связке с JavaScript и позволит веб-приложениям выполняться с гораздо большей производительностью — почти как нативные приложения в операционной системе.

    Теперь в браузере можно запускать с высокой производительностью 3D-игры, системы автоматизированного проектирования (САПР), видеоредакторы, графические редакторы, научные визуализации, ресурсоёмкие вычисления, кодировать видео — что угодно.

    Со временем многие существующие веб-приложения — почта, социальные сети, текстовые редакторы — и JavaScript-фреймворки с большой вероятностью начнут использовать WebAssembly, что существенно увеличит скорость загрузки и сильно увеличит их производительность во время работы.

    В отличие от других подходов типа Flash, которые требуют установки плагина в браузере, чтобы выполнять приложения на скорости, сравнимой с нативными приложениями, WebAssembly полностью вписывается в стандартную веб-платформу. Это открытый и совместимый стандарт, интегрированный в браузеры. Значит, разработчики могут интегрировать библиотеки WebAssembly для CPU-интенсивных вычислений (компрессия, определение лиц, физика) прямо в существующие веб-приложения, где используется JavaScript.

    WebAssembly — открытый стандарт, разработанный Mozilla, Google, Microsoft и Apple. Как можно заметить, эта группа представляет разработчиков четырёх наиболее распространённых браузеров, так что можно рассчитывать на становление wasm как всеобщего стандарта. Google обещает реализовать поддержку WebAssembly в следующей версии Chrome (57), Microsoft уже работает над реализацией в Edge.

    Низкоуровневый язык станет своеобразным дополнением к JavaScript и в конце концов должен работать везде, где работает JS: во всех браузерах и во всех средах выполнения вроде Node.js.

    Кто выиграет от использования WebAssembly? Речь идёт не только о написании новых приложений на wasm. Через компиляторы вроде Emscripten целые игры и уже готовые нативные приложения можно портировать для веба. Портируемый код C/C++ с помощью этого компилятора будет исполняться в браузере почти на той же скорости, что и нативное приложение. Кроме C/C++, для языка программирования Rust тоже реализована предварительная поддержка WebAssembly.

    Для примера, можно поиграть в демку Zen Garden (требуется браузер Firefox 52, в данный момент поддерживается только десктопная версия).


    Функции JavaScript будут вызывать функции WebAssembly и наоборот. То есть можно в рамках одной программы можно писать на высокоуровневом языке JavaScript и временами переходить на C/C++/Rust по мере необходимости.

    Разработчики начнут распространять и повторно использовать низкоуровневые модули WebAssembly без необходимости разбираться в их устройстве, как они сейчас используют минифицированные библиотеки JavaScript.

    Mozilla констатирует, что по уровню повторного использования кода и программной архитектуры стена между нативными и веб-приложениями начинает разрушаться, и это только начало. Инструменты разработчика, дебаггеры и компиляторы продолжат развиваться, также как совместимость, производительность и функциональность WebAssembly. Например, сейчас в плане Mozilla — реализовать поддержку многопоточности и параллелизма SIMD.

    «В каком-то смысле WebAssembly меняет то, что значит веб-разработчиком, — пишет Дэвид Брайант (David Bryant), руководитель разработки платформ в Mozilla, — как меняет и фундаментальные свойства веба».

    В самом деле, сейчас программы на C/C++ стало возможным портировать для выполнения в браузере, а в ближайшем будущем то же самое можно будет сделать для языков, на которых пишут мобильные приложения — Java, Swift, C#. Все они станут совместимыми со стандартной веб-платформой. Получается, что в каком-то смысле все программисты в итоге станут веб-разработчиками.
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 125
    • +3
      Наконец-то LISP захватит мир! ;-)
      • +2
        Обновил Firefox до 52, но zen garden ругается, что требуется 52-я версия :(
        • 0
          Есть ощущения что линуховой версии это не касается.
          • 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)

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

                Кстати, ошибка InvalidStateError — попытка запустить в приватном просмотре, нужен обычный.
                • +2
                  Кстати, ошибка InvalidStateError — попытка запустить в приватном просмотре, нужен обычный.
                  что!?
                  это с какого фига веб приложение вообще зависит от способа сохранения приватных данных локально?
                  • +1
                    Это из-за IndexedDB (MDN) — API для хранения данных/файлов, который работает в приватном режиме только в десктопном Chrome. Похоже, для этого необходимо хранение данных в ОЗУ и кто-то пытается реализовать это в Firefox: Bug 781982.
                • 0
                  Тоже не работает.
                  • 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 — всё, нет кросс-платформенности. А в браузере оно будет всюду. На всех платформах, которые могут показать браузер.

                            А открытый стандарт подразумевает, что это может сделать кто хочет, а не конкретный вендор, который «не хочет».
                            • 0
                              На симбе таки выпустили. Даже там уступал флешу.
                          • –1
                            Наконец-то, свою долю популярности получат всякие хромОСы и другие.
                            • +3
                              Как будто это что-то хорошее…
                            • +3
                              А еще Firefox 52 это CSS Grid.
                              • 0
                                В отличие от других подходов типа Flash, которые требуют установки плагина в браузере..

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

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

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

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

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

                                              А у меня Хром пишет, что надо установить Флеш. ЧЯДНТ?

                                              • +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
                                                              А уже же есть всякие Ява-апплеты. Что с ними не так?
                                                              • +1

                                                                Апплеты, помнится, люто тормозили и глючили при загрузке.

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

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

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

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

                                                        • 0
                                                          Производительность
                                                          • 0

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

                                                      • +3
                                                        Я не очень понимаю зачем и кому оно надо? САПР в браузере?

                                                        Если написанное в статье — правда*, то это нужно мне.

                                                        Чтобы написать для браузера свою специфичную строительную САПР. Причина — на локальных компьютерах сейчас просто зоопарк всяких файрволов, антивирусов, глюченных ОС (разных типов).

                                                        Решение перенести это всё в универсальный браузер (с установкой которого уже сами пользователи должны возиться) — логичное решение, которое давно витало в воздухе.

                                                        Не хватало только мощностей обработки данных в javascript.



                                                        * я пока ещё не разбирался, но надеюсь, что всё правда и что Chrome тоже такое поддерживает
                                                        • 0
                                                          А зачем вам нужна строительная САПР в браузере? Тот же Компас вполне работает себе на зоопарке компов.
                                                          • +1
                                                            Вы не поняли — я разработчик и собираюсь перенести в браузер свою разработку.

                                                            У меня, конечно, не AutoCAD и даже не Компас, но кое-какие пользователи имеются.
                                                          • +2
                                                            Если это все правда, то весь зоопарк файрволов и антивирусов начнет строчно учиться залезать прямо в браузеры, чтобы всю эту радость внутри браузера контролировать. В результате получится все то же самое, если не хуже.
                                                            • 0
                                                              Откуда такие выводы?

                                                              В браузере же изначально защищенная среда, в которой не удастся повредить чужие файлы.

                                                              Перенос программ в браузер никак не повлияет на безопасность данных на компьютере. Скорее наоборот, её повысит.

                                                              Т.к. сейчас всё регулируется сомнительными платными сертификатами, которые может купить любой.

                                                              А будет так, что как ни пытайся, а вне своей области памяти и данных — не вылезешь.
                                                              • 0
                                                                Ой, а то в браузерах дыр мало. А чем более развитая среда исполнения, тем удобнее эти дыры из неё эксплуатировать.
                                                                • 0
                                                                  Так большинство этих дыр из-за того, что браузеры пытаются выполнить что-то вне своей среды.
                                                                  • 0
                                                                    Если мы хотим (мы не хотим, но тут про это пишут) фотошоп в браузере, то без доступа во вне никак не получится.
                                                                    • 0
                                                                      Это только до того момента, пока не появится «opencl.js». Тогда и Фотошоп можно будет перенести в браузер.
                                                                • 0
                                                                  Расскажите это касперскому, который Free.
                                                                  Он уже встраивает свой сертификат в https трафик. Правда при этом установщик забыл добавить сертификат, которым это всё подписано, в доверенные корневые сертификаты.

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

                                                              (проверку буфера обмена мы делаем и если там пусто, пункты меню неактивны. а вот с пустой формы вырезается и копируется вполне отлично)
                                                              • +3
                                                                А теперь на нем пусть напишут флеш ) 100500 флеш-мувиков не должны кануть в лету! )
                                                                • –1
                                                                  Flash Умер, да здравствует Flash!
                                                                  • +3
                                                                    Шел 2017 год а многопоточность всё ещё в плане.
                                                                    • +2
                                                                      Сделали же ещё в прошлом релизе, работает если руками включить и с ограниченным количеством плагинов
                                                                      • 0
                                                                        Там была многопроцессность. Если я правильно помню, то там идея в том чтобы каждую вкладку обрабатывать в отдельном процессе. От этого ограничение в 1 поток на рендер 1 вкладки не пропадёт. Для наглядного сравнение запустите html5 игру в лисе и в хроме, посмотрите на загрузку цпу и на фпс в игре.
                                                                      • 0
                                                                        Firefox 48: многопроцессность (и как её включить)
                                                                        browser.tabs.remote.autostart — true
                                                                        browser.tabs.remote.force-enable — true
                                                                      • +2
                                                                        Очень интересно, как из WebAssembly происходит доступ к выводу графики
                                                                        • 0

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

                                                                          • 0
                                                                            Отрисовать битмап какой-нибудь Skia и отправить байтмассивом в JS. А тот уже на канвасе нарисует.
                                                                            • –1
                                                                              Ужас какой! А говорят про фотошопы в браузере.
                                                                              • +1
                                                                                Ну а как по-вашему какой-нибудь GIMP работает? Отрисовывает битмап в памяти и отправляет байтмассивом оконной подсистеме.
                                                                                • –1
                                                                                  Я в общих чертах знаю, как работает Х11. Разве GIMP не использует никакой технологии ускорения вывода?
                                                                                  • 0
                                                                                    Так оно всё равно сводится к «нарисовать битмап в памяти и отправить в видеокарту»
                                                                            • 0
                                                                              > как из WebAssembly происходит доступ к выводу графики

                                                                              Еще документов через D3
                                                                              • 0

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

                                                                              • 0
                                                                                Начало конца эпохи JS?
                                                                                • +1
                                                                                  Скорее наоборот, теперь можно по сути написать низкоуровневый движок с api,
                                                                                  к которому можно достучаться через жс, учитывая скорость развития и появления
                                                                                  всевозможных фреймворков — это очень и очень здорово.
                                                                                • +1
                                                                                  Они убили Java! Сволочи!
                                                                                  • 0
                                                                                    И что мешало использовать какие-нибудь ява-апплеты?
                                                                                    • 0

                                                                                      Нет, не убили, см GWT, TeaVM.

                                                                                    • +2
                                                                                      А потом оно начнет в вэб-САПРе и фотошопе рекламу показывать на пол-экрана, потому что надо отбивать новую технологию.
                                                                                      После этого усталые парни с красными глазами в одинаковых корпоративных детских футболках нам объявят, что старые оси и слабое железо больше не поддерживаются новым супер-стандартом и всем надо сходить в магазин и купить новое, если в интернет хотим выходить.
                                                                                      И окончательно покончат с пиратским ПО — ведь они только ради этого всю эту затею пилят.
                                                                                      • +1
                                                                                        Поэтому, пока не поздно, надо поддерживать хороших людей, делающих бесплатное или очень дешевое ПО.

                                                                                        А не говорить, допустим (я не про вас, но такое поведение часто встречается)

                                                                                        — у вас некрасивые кнопки в интерфейсе, я лучше Photoshop с торрентов бесплатно скачаю.

                                                                                        Потому как результат, действительно, немного предсказуем.
                                                                                        • 0
                                                                                          Я не понимаю, что помешает скачать этот web-assembly, крякнуть и захостить локально на каком-нибудь IIS?
                                                                                          • 0
                                                                                            Проверка лицензий онлайн. Локально вы в нем скорее всего мало что запустите.
                                                                                            • 0
                                                                                              Подобные механизмы когда-то мешали взламывать ПО?
                                                                                              Скачают, сломают, и будут хостить локально.
                                                                                            • 0

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

                                                                                              • 0
                                                                                                Но тогда и смысла от WebAssembly не много.
                                                                                          • 0
                                                                                            Как я понимаю WebAssembly для веба что-то вроде NDK для Android, верно?
                                                                                            • 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
                                                                                                          Тормозит невыносимо, вкладки подвисают на несколько секунд, а то и минут
                                                                                                          • 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
                                                                                                                              Я думаю этот процесс всеже нельзя назвать Компиляцией:)
                                                                                                                            • 0
                                                                                                                              его не нужно компилировать как JS. Там идет просто проверка и перегон в машинный код. Как я уже сказал, разница в 25 раз. Те если запустить большой проект — к примеру игру. То она секунд 10 просто переваривает JS а потом еще около минуты — его оптимизирует — на сколько я понимаю делает JIT.

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

                                                                                                                              Да ну, вот же выше демка с садом — wasm делает все тоже самое. Сначала прежде чем запуститься долго комплит загружая все ядра процессора при этом.
                                                                                                                          • 0
                                                                                                                            Юнити давно умеет компилить в asm.js. Что, впрочем, не особо и помогает.

                                                                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.