Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Sheridan, Вы писали:
_>>>Хы, ну попробуй сделать с помощью этого пример из моего первого сообщения. ))) S>>А нафига мне в клиента плеваться кодом который надо будет еще исполнять? Я могу всё это быстренько и на сервере нарулить. Понапридумают реактов, блин а потом сайты тормозят не по детски.
_>Ты скажи честно, ты сайт то, показанный в первом сообщение, открывал или нет? ))) А то похоже ты даже не представляешь о чём идёт речь... )))
По ссылке ничего такого не пишут, наоборот. А вот сами авторы вебасма обещают DOM, только непонятно когда, давно уже обещают. Еще где-то писали, что эта задача для них не очень приоритетная, а так ведь можно очень надолго затянуть или вообще забить.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>Вообще то игры — это только пример того, что вполне нормально для тяжёлых приложений иметь определённые ограничения на запуск и при этом быть успешными. А так это касается не только игр, но и любого тяжёлого ПО (вот например такое http://formit360.autodesk.com сразу же станет на порядок эффективнее от прихода wasm).
За счет чего станет эффективнее на порядки? WebGL и так нейтивный. HLSL закидываются в него точно так же.
Вызовы нейтивной подсистемы из JS в подобных приложениях происходят со скоростью кликанья мышки, JS должен справляться.
_>Так GUI построенный на базе HTML во-первых достаточно убогий (посмотри на список доступных контролов в современных GUI библиотеках и в HTML), а во-вторых рендеринг через DOM весьма тормозной. Различные JS библиотеки (типа ExtJS) пытаются решать эти проблемы разработкой своих контролов и различными оптимизациями DOM, но всё это не эффективно на практике. Если же у тебя есть C++ приложение и предоставленная OpenGL поверхность, то ты просто берёшь одну из готовых мощных GUI библиотек и автоматически получаешь быстрый и профессиональный GUI. Естественно это актуально только для всяческих сложных сайтов (по сути веб приложений), а не для обычных "каталогов текста с картинками". )
Интресно, какой получится размер подобной загружаемой библиотеки GUI? ))
пишут, что что-то будет. Ops>По ссылке ничего такого не пишут, наоборот. А вот сами авторы вебасма обещают DOM, только непонятно когда, давно уже обещают. Еще где-то писали, что эта задача для них не очень приоритетная, а так ведь можно очень надолго затянуть или вообще забить.
Так там туда же ссылка и стоит. Что-то будет точно — а вот с какими ограничениями — уже будет видно по факту. Что они подразумевают под opaque reference types — мне вот не очень понятно... если через протаскиваение persistent GC handles — то опять надо будет обязательно все ссылки зануливать, что катастрофой в общем-то тоже не будет. Утечки просто будут и крики <мой браузер> опять сожрал всю память.
Здравствуйте, Ops, Вы писали:
_>>А вот например всяким кинотеатрам и т.п. сервисам возможно будет очень интересно наладить персональные зашифрованные каналы доставки контента. ) Ops>Вскроют. Это в принципе нежизнеспособная концепция, когда клиент должен показывать пользователю расшифрованный контент, найти способ добраться для него лишь вопрос джонеуловимости.
Формально — конечно. Вопрос в сложности) И wasm по своей природе (можно же загружать "новый" плеер хоть на каждый новый фильм) существенно её увеличивает — возможно тогда проще какой-нибудь HDCP Stripper использовать, чем ломать такую штуку. )))
Здравствуйте, fddima, Вы писали:
F> Так там туда же ссылка и стоит.
Думал, ты про пост, ссылки дальше не смотрел. F>Что-то будет точно — а вот с какими ограничениями — уже будет видно по факту.
Когда будет-то? Они не торопятся, и явно писали, что задача не из первых. А ведь для многих это ключевой момент. F>Что они подразумевают под opaque reference types — мне вот не очень понятно... если через протаскиваение persistent GC handles — то опять надо будет обязательно все ссылки зануливать, что катастрофой в общем-то тоже не будет. Утечки просто будут и крики <мой браузер> опять сожрал всю память.
Кстати, у них FAQ интересное, "вебасм — это не замена JS, а дополнение", так что если что-то и прикрутят, это совсем не обязательно будет полноценным API, вполне может оказаться неудобным костылем.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>Формально — конечно. Вопрос в сложности) И wasm по своей природе (можно же загружать "новый" плеер хоть на каждый новый фильм) существенно её увеличивает — возможно тогда проще какой-нибудь HDCP Stripper использовать, чем ломать такую штуку. )))
Нет, вопрос в повсеместном использовании и в реализации. Сколько не защищай, на соседнем сайте нет никакой защиты, так что твой поток, если он не полностью уникальный, никто и ломать не будет, а контент все равно утечет. Говорю же, вопрос в джонеуловимости. Ну и какой смысл тогда вкладываться в защиту этого Джо?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vdimas, Вы писали:
_>>Вообще то игры — это только пример того, что вполне нормально для тяжёлых приложений иметь определённые ограничения на запуск и при этом быть успешными. А так это касается не только игр, но и любого тяжёлого ПО (вот например такое http://formit360.autodesk.com сразу же станет на порядок эффективнее от прихода wasm). V>За счет чего станет эффективнее на порядки? WebGL и так нейтивный. HLSL закидываются в него точно так же. V>Вызовы нейтивной подсистемы из JS в подобных приложениях происходят со скоростью кликанья мышки, JS должен справляться.
Ну так на шейдерах то только прорисовка. А надо ещё просчитывать сам мир, взаимодействия объектов и т.п. )
_>>Так GUI построенный на базе HTML во-первых достаточно убогий (посмотри на список доступных контролов в современных GUI библиотеках и в HTML), а во-вторых рендеринг через DOM весьма тормозной. Различные JS библиотеки (типа ExtJS) пытаются решать эти проблемы разработкой своих контролов и различными оптимизациями DOM, но всё это не эффективно на практике. Если же у тебя есть C++ приложение и предоставленная OpenGL поверхность, то ты просто берёшь одну из готовых мощных GUI библиотек и автоматически получаешь быстрый и профессиональный GUI. Естественно это актуально только для всяческих сложных сайтов (по сути веб приложений), а не для обычных "каталогов текста с картинками". ) V>Интресно, какой получится размер подобной загружаемой библиотеки GUI? ))
А можешь сам посмотреть например тут http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos — это примеры Qt приложений, скомпилированных под браузер (причём не в wasm, а в js). Самое забавное, что даже при компиляции в js этот интерфейс выглядит более отзывчивым, чем многие GUI на современных сайтах (сделанные с помощью JS GUI библиотек). А вот что это всё превратится с приходом wasm...
Здравствуйте, alex_public, Вы писали:
_>Ну так на шейдерах то только прорисовка. А надо ещё просчитывать сам мир, взаимодействия объектов и т.п. )
Ну если только физика, т.е. если мир слишком "активный"...
А так-то, даже если сцена сложная, но изменяется редко или часто изменяются только параметры сцены или небольшая группа объектов при уже загруженных ресурсах (изменение освещения, назначения разных уже предзагруженных текстур в зависимости от удалённости объектов), то заметного буста быстродействия не будет, ес-но.
_>А вот что это всё превратится с приходом wasm...
Посмотрим.
Браузер — это инфраструктура доставки исполняемого/интерпретируемого кода на сторону клиента. Не только доставки, но и кеширования.
Если с кешированием общих (для разных сайтов) библиотек разберутся, то может и взлетит...
Главный вопрос — когда?
Мы с тобой обсуждали несколько месяцев назад относительно того, что на прямо сейчас происходит натуральное "безвременье" в браузерных технологиях. Старые плагинные технологии уже преданы анафеме, но полноценной замены еще нет.
Здравствуйте, alex_public, Вы писали:
_>По идее без проблем. Правда для ютуба это не особо надо (что им там, дополнительную кнопочку в плеер прилепить что ли?). А вот например всяким кинотеатрам и т.п. сервисам возможно будет очень интересно наладить персональные зашифрованные каналы доставки контента. )
"без проблем"... Я бы не был так оптимистичен.
WebAsm в принципе не может более того что может JavaScript который может рисовать только путем манипуляции DOM и методами <canvas>. <canvas> требует bitmap по спецификации, а это CPU rasterization.
А на самом деле всё еще хуже, в WebAsm, насколько я знаю, нет еще механизма обращения к DOM методам. Т.е. рисовать он не может, только что-то считать.
Ну и к тому же memory safety никто не отменял. Т.е. весь memory доступ должен быть обернут в вызовы каких-то функций. Т.е. это вот
while(p < end) ++p = 0;
будет достаточно далеко от выхлопа native C compiler.
На самом деле WebAsm нужно расценивать как byte codes, а всю инфраструктуру как нечто очень похожее на среду JavaVM.
Здравствуйте, vdimas, Вы писали:
_>>А вот что это всё превратится с приходом wasm... V>Посмотрим. V>Браузер — это инфраструктура доставки исполняемого/интерпретируемого кода на сторону клиента. Не только доставки, но и кеширования. V>Если с кешированием общих (для разных сайтов) библиотек разберутся, то может и взлетит... V>Главный вопрос — когда? V>Мы с тобой обсуждали несколько месяцев назад относительно того, что на прямо сейчас происходит натуральное "безвременье" в браузерных технологиях. Старые плагинные технологии уже преданы анафеме, но полноценной замены еще нет. V>Чёрти что, как по мне. Мир сошел с ума...
Ну так ты же сам пишешь, что в принципе JS с WebGL уже сам может почти всё. Единственно, что ему может не хватать, это производительности в некоторых случаях (например если мы хотим написать свой плеер видео, которому соответственно придётся декодировать h.264/h.265) и доступа к функциям ОС (например для общения со всякими железками). Первую проблему очевидно решает как раз wasm. А вторую в какой-то степени решает Native messaging API, позволяющий данному JS скрипту общаться с внешним нативным приложением, естественно имеющим доступ ко всему OS API (однако установить это приложение как плагин браузера не выйдет — нужная нормальная инсталляция).
Здравствуйте, c-smile, Вы писали:
_>>По идее без проблем. Правда для ютуба это не особо надо (что им там, дополнительную кнопочку в плеер прилепить что ли?). А вот например всяким кинотеатрам и т.п. сервисам возможно будет очень интересно наладить персональные зашифрованные каналы доставки контента. ) CS>"без проблем"... Я бы не был так оптимистичен. CS>WebAsm в принципе не может более того что может JavaScript который может рисовать только путем манипуляции DOM и методами <canvas>. <canvas> требует bitmap по спецификации, а это CPU rasterization.
Ты забываешь про WebGL. )))
CS>А на самом деле всё еще хуже, в WebAsm, насколько я знаю, нет еще механизма обращения к DOM методам. Т.е. рисовать он не может, только что-то считать.
Мы можем спокойно написать приложение на OpenGL, откомпилировать его emscripten и запустить в браузере. Причём это работало ещё и до wasm (с компиляцией в js), просто было не так эффективно по быстродействию. Хотя для определённых целей (включая сложные Qt интерфейсы, вроде таких http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos) даже такого хватало. А теперь будет ещё намного быстрее.
CS>На самом деле WebAsm нужно расценивать как byte codes, а всю инфраструктуру как нечто очень похожее на среду JavaVM.
Байткод бывает разный. Бывает JVM, а бывает LLVM. )
Здравствуйте, alex_public, Вы писали:
_>Ну так ты же сам пишешь, что в принципе JS с WebGL уже сам может почти всё.
WebGL не может ничего.
Это как голый AutoCAD без плагинов, где можно рисовать только плоскости, базовые фигуры и т.д.
Далеко ты таким макаром не уедешь, ес-но.
Это не то же самое, что работать с полным набором плагинов для архитектурного проектирования, к примеру.
Т.е. нужно будет портировать кучу либ на wasm.
А потом как-то разбираться с их версионированием и кешированием.
Потому что размер таких полноценных либ сегодня — десятки метров.
_>Единственно, что ему может не хватать, это производительности в некоторых случаях (например если мы хотим написать свой плеер видео, которому соответственно придётся декодировать h.264/h.265) и доступа к функциям ОС (например для общения со всякими железками).
Чего в JS не хватает — это нормального языка программирования и хорошо структурированных библиотек к нему. ))
Код клиентских приложений может быть (и должен быть) довольно-таки сложен.
Я пару раз пытался читать обзоры того, что сейчас пользуют из либ для JS — голова идёт кругом.
Там происходит идеальнейший в природе Хаос.
Я же писал уже, что Сервелат еще жив в корпоративе по банальной причине — клиента можно писать на вменяемом C# с кучей хорошо стыкующихся друг с другом либ к нему.
А тут экосистему языков и библиотек к ним поверх wasm еще только предстоит создать.
Т.е. необходимо будет портировать и переосмыслить структуру гигантских пластов исходников.
Т.е., если в середине 90-х "из ничего" за 2-3 года появилось "всё", то сейчас всё изменилось, инерционность веба дикая.
Как и прежде, я вангую еще лет 5 минимум на "созревание" этой технологии.
При том, что ей уже пошёл 6-й год от первой демонстрации "вживую"...
_>Первую проблему очевидно решает как раз wasm. А вторую в какой-то степени решает Native messaging API, позволяющий данному JS скрипту общаться с внешним нативным приложением, естественно имеющим доступ ко всему OS API (однако установить это приложение как плагин браузера не выйдет — нужная нормальная инсталляция).
И обратиться из кода страницы к такому приложению выйдет только в том случае, если оно получено из надёжного источника. Например, в WIN 8 и выше можно запустить по специальной браузерной ссылке установленное приложение. Это ссылка на страничку этого приложения в Магазине. Если приложение уже стоит — оно запустится. Если еще не стоит — откроется Магазин и предложит установить.
Осталось придумать, как ровно таким же образом из надёжных источников получать библиотеки для wasm.
Потом предкомпиллять их (АОТ) при инсталляции.
А потом посмотреть на всё это с высоты птичьего полёта и сделать вот так ...
Будет та же плагинная система, вид сбоку. ))
Здравствуйте, 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.
Здравствуйте, vdimas, Вы писали:
V>Чёрт-те что, как по мне. Мир сошел с ума...
Это не мир сошел с ума, это ты на него смотришь через амбразуру старых задач. Все эти окошки с кучей кнопочек, пимпочек и фитюлечек уже мало кому интересны. Типичный пользователь сейчас увидел твое приложение 5 минут назад, а еще через 5 про него забудет. И смотрит этот пользователь на него через смартфон, планшет или киоск производства мастера Лю из китайского аналога Усть-Зажопинска. Т.е. в качестве устройства ввода там никаких клавиатур, мышей и тачпадов, только собственный палец, елозящий по подглюкивающему тач-скрину. И рассчитывать на то, что там будет что то более менее стандартное, окромя браузера тоже не приходится.
Здравствуйте, vdimas, Вы писали:
_>>Ну так ты же сам пишешь, что в принципе JS с WebGL уже сам может почти всё. V>WebGL не может ничего. V>Это как голый AutoCAD без плагинов, где можно рисовать только плоскости, базовые фигуры и т.д. V>Далеко ты таким макаром не уедешь, ес-но. V>Это не то же самое, что работать с полным набором плагинов для архитектурного проектирования, к примеру. V>Т.е. нужно будет портировать кучу либ на wasm. V>А потом как-то разбираться с их версионированием и кешированием. V>Потому что размер таких полноценных либ сегодня — десятки метров.
В принципе если библиотека использует только стандартную библиотеку C++ в сочетание с какой-то разновидностью OpenGL/OpenAL, то всё "портирование" сведётся к просто перекомпиляции под emscripten. Т.е. очень многие движки заведутся "с ходу". )
Скажем для портирования SDL (которая теперь кстати входит в стандартное API emscripten https://github.com/kripken/emscripten/tree/master/system/include) им наверное (я сам не смотрел детали) пришлось добавить на уровне js-кода только простейшие вещи (поддержку получения событий от мышки с клавой и всякие мелочи типа установки заголовка окна, перехода в полноэкранный режим и т.п.). А теперь любое приложение, работающее на базе SDL (а таких не мало) будет собираться под браузер простой перекомпиляцией. Причём это всё было ещё до wasm, просто под js. А wasm всего лишь добавит к этой уже существующей инфраструктуре быстродействие близкое к нативному.
_>>Единственно, что ему может не хватать, это производительности в некоторых случаях (например если мы хотим написать свой плеер видео, которому соответственно придётся декодировать h.264/h.265) и доступа к функциям ОС (например для общения со всякими железками). V>Чего в JS не хватает — это нормального языка программирования и хорошо структурированных библиотек к нему. )) V>Код клиентских приложений может быть (и должен быть) довольно-таки сложен. V>Я пару раз пытался читать обзоры того, что сейчас пользуют из либ для JS — голова идёт кругом. V>Там происходит идеальнейший в природе Хаос.
Ну так сейчас вот уже C/C++ добавились. Обещается в ближайшее время Rust. Может потом и всякие Java/C# подтянутся (хотя не очень понятно зачем они нужны для wasm, т.к. их код обычно не намного более быстродействующий, чем JS)...
V>Т.е., если в середине 90-х "из ничего" за 2-3 года появилось "всё", то сейчас всё изменилось, инерционность веба дикая. V>Как и прежде, я вангую еще лет 5 минимум на "созревание" этой технологии. V>При том, что ей уже пошёл 6-й год от первой демонстрации "вживую"...
Нуу использовать то на практике думаю можно будет уже прямо в этом году. А вот повсеместное распространение она не факт что и через 5 лет получит, просто потому что она реально не везде нужна. )))
_>>Первую проблему очевидно решает как раз wasm. А вторую в какой-то степени решает Native messaging API, позволяющий данному JS скрипту общаться с внешним нативным приложением, естественно имеющим доступ ко всему OS API (однако установить это приложение как плагин браузера не выйдет — нужная нормальная инсталляция). V>И обратиться из кода страницы к такому приложению выйдет только в том случае, если оно получено из надёжного источника. Например, в WIN 8 и выше можно запустить по специальной браузерной ссылке установленное приложение. Это ссылка на страничку этого приложения в Магазине. Если приложение уже стоит — оно запустится. Если еще не стоит — откроется Магазин и предложит установить. V>Осталось придумать, как ровно таким же образом из надёжных источников получать библиотеки для wasm. V>Потом предкомпиллять их (АОТ) при инсталляции. V>А потом посмотреть на всё это с высоты птичьего полёта и сделать вот так ... V>Будет та же плагинная система, вид сбоку. ))
Так для wasm как раз не требуется надёжного источника, т.к. его исполнение ограничено песочницей браузера. ) В этом и есть главный смысл. )
да блин..
А вот что это всё превратится с приходом wasm...
...
