Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, c-smile, Вы писали:

_>>>По идее без проблем. Правда для ютуба это не особо надо (что им там, дополнительную кнопочку в плеер прилепить что ли?). А вот например всяким кинотеатрам и т.п. сервисам возможно будет очень интересно наладить персональные зашифрованные каналы доставки контента. )
CS>>"без проблем"... Я бы не был так оптимистичен.
CS>>WebAsm в принципе не может более того что может JavaScript который может рисовать только путем манипуляции DOM и методами <canvas>. <canvas> требует bitmap по спецификации, а это CPU rasterization.

_>Ты забываешь про WebGL. )))

WebGL это тоже canvas

gl = canvas.getContext('webgl')

CS>>А на самом деле всё еще хуже, в WebAsm, насколько я знаю, нет еще механизма обращения к DOM методам. Т.е. рисовать он не может, только что-то считать.

_>Мы можем спокойно написать приложение на OpenGL, откомпилировать его emscripten и запустить в браузере. Причём это работало ещё и до wasm (с компиляцией в js), просто было не так эффективно по быстродействию. Хотя для определённых целей (включая сложные Qt интерфейсы, вроде таких http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos) даже такого хватало. А теперь будет ещё намного быстрее.

Только если WebAsm'у позволено обращаться напрямую к методам DOM. Пока — нет.

CS>>На самом деле WebAsm нужно расценивать как byte codes, а всю инфраструктуру как нечто очень похожее на среду JavaVM.

_>Байткод бывает разный. Бывает JVM, а бывает LLVM. )

JVM или LLVM — разницы в данном контексте нет. Эти байткоды напрямую к памяти обращаться не могут — sandboxing.