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

_>>И мне вообще странно представить, что кто-то (ну естественно кроме авторов соответствующих библиотек) мог подумать об идее рисовать кнопочки руками — это уж слишком стандартная в индустрии задача, чтобы плодить свои велосипеды в прикладных приложениях, вместо использования готовых библиотек.
I>Мне трудно понять, что же от тебя можно ожидать, особенно с учетом того, что ты регулярно хвастаешься, как твои наколеночные велосипеды обгоняют всё что угодно.

В рисовании кнопочек? ))
Написать не забыл, включить голову забыл...


_>>Эммм, WebGL — это вообще не движок. ))) Это просто бальный доступ для твоего кода к видеокарте пользователя и всё.
I>Джижок, engine, это настолько широкий термин, что крайне странно к этому придираться.
I>API рендеринга вполне себе подходит под термин "движок"

Что ты не догоняешь малость...
Требуемый АПИ и так есть, достаточно было дать к нему доступ.

Т.е., в wasm нет своего уникального АПИ графики, есть "открытая дверь" к одной из версий OpenGL — GLES.
Ровно это же АПИ использует внутренний движок рендеринга браузера, поэтому я и писал рядом, что wasm имеет такие же графические ср-ва оперирования отображением в своём "окне", как и хост-браузер.

Emscripten targets the WebGL-friendly subset of OpenGL ES 2.0. This is the set of GL ES commands that map directly to WebGL, so that each GL command has a roughly direct mapping to WebGL.

I>Все как я и говорил — экзотический случай, никаких шансов интеграции с другими системами/компонентами.

Как это "никаких шансов", если они используют третьесторонние библиотеки для OGL? ))
Ты не в курсе, похоже, как умеют работать те библиотеки — им можно подать уже готовый контекст и вью-порт.

И это только касательно GUI.
А касательно любого другого функционала — линкуй себе в проект любые третьесторонние либы для нужной функциональности, какие проблемы?


I>Именно. А еще интеграция — любой крупный UI как правило сборная солянка частей от разных команд и даже вендоров. И это не редкость.

Как и везде.


I>Современный подход — UI определяет API и данные. Отсюда ясно, что избавляемся от лишних приседаний сравнивая UI 10 и 20 летней давности.
I>Схема взаимодействия проще, API проще, данные проще, стейтменеджмент гораздо более эффективный.

Здесь брехня каждое слово.
В фронтенде всё это сложнее.
Единственный его плюс — это способ "размещения" и "обновления" приложений.
Вот тут он впереди планеты всей оказался по многим историческим причинам.
В т.ч. потому что отрубили плагинную систему.

А так-то в Сервелате всё тобой перечисленное в разы продвинутей было.

Ну ниче... Допилят GC для wasm и очередная инкарнация WPF/Cервелата туда проникнет. ))
А может быть даже и раньше, судя по скорости разработки Blazor.

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

_>>И мне вообще странно представить, что кто-то (ну естественно кроме авторов соответствующих библиотек) мог подумать об идее рисовать кнопочки руками — это уж слишком стандартная в индустрии задача, чтобы плодить свои велосипеды в прикладных приложениях, вместо использования готовых библиотек.
I>Мне трудно понять, что же от тебя можно ожидать, особенно с учетом того, что ты регулярно хвастаешься, как твои наколеночные велосипеды обгоняют всё что угодно.

В рисовании кнопочек? ))
Написать не забыл, включить голову забыл...


_>>Эммм, WebGL — это вообще не движок. ))) Это просто бальный доступ для твоего кода к видеокарте пользователя и всё.
I>Джижок, engine, это настолько широкий термин, что крайне странно к этому придираться.
I>API рендеринга вполне себе подходит под термин "движок"

Что-то ты не догоняешь малость...
Требуемый АПИ и так есть, достаточно было дать к нему доступ.

Т.е., в wasm нет своего уникального АПИ графики, есть "открытая дверь" к одной из версий OpenGL — GLES.
Ровно это же АПИ использует внутренний движок рендеринга браузера, поэтому я и писал рядом, что wasm имеет такие же графические ср-ва оперирования отображением в своём "окне", как и хост-браузер.

Emscripten targets the WebGL-friendly subset of OpenGL ES 2.0. This is the set of GL ES commands that map directly to WebGL, so that each GL command has a roughly direct mapping to WebGL.

I>Все как я и говорил — экзотический случай, никаких шансов интеграции с другими системами/компонентами.

Как это "никаких шансов", если они используют третьесторонние библиотеки для OGL? ))
Ты не в курсе, похоже, как умеют работать те библиотеки — им можно подать уже готовый контекст и вью-порт.

И это только касательно GUI.
А касательно любого другого функционала — линкуй себе в проект любые третьесторонние либы для нужной функциональности, какие проблемы?


I>Именно. А еще интеграция — любой крупный UI как правило сборная солянка частей от разных команд и даже вендоров. И это не редкость.

Как и везде.


I>Современный подход — UI определяет API и данные. Отсюда ясно, что избавляемся от лишних приседаний сравнивая UI 10 и 20 летней давности.
I>Схема взаимодействия проще, API проще, данные проще, стейтменеджмент гораздо более эффективный.

Здесь брехня каждое слово.
В фронтенде всё это сложнее.
Единственный его плюс — это способ "размещения" и "обновления" приложений.
Вот тут он впереди планеты всей оказался по многим историческим причинам.
В т.ч. потому что отрубили плагинную систему.

А так-то в Сервелате всё тобой перечисленное в разы продвинутей было.

Ну ниче... Допилят GC для wasm и очередная инкарнация WPF/Cервелата туда проникнет. ))
А может быть даже и раньше, судя по скорости разработки Blazor.