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

Для начала проясню один момент, который ты в очередной раз себе нафантазировал. Похоже у тебя почему-то создалось впечатление, что у мы там играемся с треугольниками на шейдерах ради показа кнопки. Да, глубоко внутри соответствующей библиотеки оно на самом деле так и происходит, но мы этого всего не видим, т.к. пользуемся исключительно высокоуровневым API классической GUI библиотеки. И да, она естественно написана не нами. Т.е. мы просто перешли с Qt (которая не нужна, если ты не пытаешься писать кроссплатофермнное приложение, выглядящее нативно на каждой из платформ) на другую библиотеку со своей оригинальной прорисовкой (всё равно в браузере нет никаких своих платформенных стандартов и каждый рисует как хочет).

_>>У меня сейчас есть клиентское приложение для браузера, в котором от DOM есть ровно один элемент — один большой canvas и всё. Всё остальное рисуется самим приложением, причём на выходе имеем красивые 3D окна с теням и т.п. украшательствами. При этом список из 10000 элементов прокручивается при 60 fps с нагрузкой процессора в 0,2% (по измерялке браузера).
I>Итого- сложность на уровне лабораторной работы курс "основы компьютерной графики" студента второго курса среднего института. Красивости, тени и тд это даже упоминать смешно.
I>Чтото навроде пилят люди на курсах "фронтенд за 21 урок", где канвасу посвящается целых 1 или даже 2 занятия.

Ты похоже сильно путаешь просто canvas и webgl. Я подозреваю, что 99% фронтендеров не то что не способны написать подобную библиотеку, а даже банально не знакомы с необходимыми для этого понятиями.

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

I>Кстати, всего несколько лет назад ты хихикал и стебался с этого канваса, рассказывал какой он весь медленный А теперь ты рассказываешь, какой он быстрый Забавная трансформация, не правда ли?

Ты меня похоже с кем-то путаешь. ) Собственно голый canvas я вообще вряд ли когда-то обсуждал, т.к. там нечего обсуждать. А вот с webgl у меня всегда были хорошие отношения (я даже на этот форум примеры на нём выкладывал несколько лет назад). И да, webgl медленнее десктопных аналогов, но с учётом быстродействия современных видеокарт это можно заметить только на AAA играх и т.п., а вот прорисовка любых возможных интерфейсов не нагрузит современную видеокарту даже на 1%. Ну а для потенциальных AAA-игр (хотя не представляю откуда в них будут загружать сотни гигабайт текстур) и всяких там вычислений (нейросетки и т.п.) сейчас усиленно пилят webgpu (по образу и подобию Vulkan — https://github.com/gfx-rs/wgpu-native).

Кстати, используемая нами GUI библиотечка уже имеет отдельный бэкенд на webgpu, видимо из соображений перфекционизма (т.к. для их целей webgl с головой хватает и ни один пользователь не сможет ощутить улучшение). Но я их в этом поддерживаю и переключусь на этот бэкенд, как только webgpu станет поддерживаться всеми браузерами.

I>Текущий UI, это на 80% смешаный — функциональные элементы пополам с контентом.
I>Если же ограничиться только функциональными, то получим UI конца нулевых на MFC или Winforms, и сразу становится ясно, что этот вариант остался давно в прошлом.
I>Я напомню — MFC, Winforms, WPF и многие другие вобщем слились, хотя обладали очень крутыми возможностями. То есть, не в крутости дело.

Угу, они все слились в пользу Qt, которая точно такая же, только кроссплатформенная. )))

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

I>Какие возможности твоего решения?
I> Ты сделал поддержку стилей? Ну что бы по десять раз на неделе сотни мелких фиксов в стилях делать не пересобирая вообще все и не ломая то тут, то там?

Да, вся прорисовка библиотеке полностью управляется стилями — можешь в один клик сделать всем окнам прозрачный фон или розовый и него зелёные кнопки с жёлтым жирным текстом курсивом. Однако у нас за всё время использования ни разу не возникло желания заниматься подобным — дефолтный стиль от разработчиков библиотеки полностью устраивает. Ну и да, стили естественно настраиваются не каким-то мутным текстовым DSL'ем, а нормальной такой жёстко типизированной структуркой.

I> А сколько времени надо, что бы новому кастомеру вообще все стили переделать?

В теории мгновенно. А на практике такого никогда не будет — мы не на аутсорсе и менять что-то по прихоти отдельного клиента не собираемся в принципе.

I> А она на всех девайсах заработает и адекватно смасштабируется?

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

Лично у нас был большой опыт написания приложений (на Qt), работающих под любой экран, так что тут вышло всё хорошо.

I> А можно ли твой компонент встроить как отдельный элемент UI другого приложения, да так, что бы то, другое, могло подменить все стили, лайоут, итд твоего?

Какой ещё компонент? ))) У нас приложение! Ты вот можешь встроить AutoCAD в Photoshop? )))

I> А лайоут у тебя как менять можно? А респонсив умеет? А флексы, флоаты и тд честные?

Все контролы естественно размещаются автоматически и динамически. Т.е. я поверну телефон на 90 градусов и все они тут же автоматически перестроятся под оптимальный размер и позицию. Причём мне для этого ничего делать не надо. всё само. Вообще такие вещи являются нормой в GUI библиотеках уже десяток лет (в Qt всё было тоже самое) и только в мире веб-фронтенда такие простейшие и очевидные вещи до сих пор вызывают вопросы.

I> А какой, собственно, контент оно умеет, кроме твоего захардкоженого списка? Сколько времени ты будешь пилить список, где каждый элемент это кастомная панель, которая может содержать вообще всё — фото, иконка, кнопки, прогрессбар, фрагмент текста, тайтл, футер ? Разумеется, начинка меняется по сотне раз на неделю. Ну вот надо так и всё.

Конечно это высосанный тобой из пальца пример, но почему бы не порассуждать и о таком. Собственно не вижу никаких проблем с реализаций, надо только в начале определиться с тем, в каком формате ты собираешься хранить подобные данные, подготовив соответствующие сериализаторы и десериализаторы в типы твоего языка. И как ты понимаешь, это всё не зависит от используемого средства для отображения (DOM, WebGL или вообще WinAPI), а зависит исключительно от самих данных. А вот имея уже соответствующую иерархию объектов в памяти твоего приложения, можно поговорить о визуализации. И подозреваю, что с помощью, упоминаемой мною, библиотечки это будет гораздо проще, чем с помощью DOM. Во всяком случае полноценный рендер из markdown, находящийся в примерах к библиотеке (там такое классическое приложение с разделённым пополам экраном, слева многострочное поле ввода для markdown, а справа его визуализация), занимает что-то около 150 строчек кода.


I> По таким причинам канвас-UI не прижился — первым делом сам собой вырастает самопальный DOM с самопальным подобием css...
I>Попробуй дать внятный ответ на все вопросы выше и станет очевидно.
I>Еще 8 лет назад было полно экспериментов на канвасе и было модно пилить уи там. Но не прижилось, по вполне конкретным причинам.
I>На самом деле canvas UI кое где используется — там, где нужны в основном фукнкциональные элементы, часто нестандартные. Доля таких случаев крайне невелика. Как только появляется какой то контент, поверх канваса нарастает слой DOM. Типичные рисовалки так и сделаны — контент это дивы поверх канвасного слоя.

Всё оно отлично прижилось (я естественно про WebGL, а не какие-то там DOM поделки, типа голой canvas). ) Просто доля настоящих приложений (но при этом работающих в браузере) пока что ничтожна по сравнению с бесчисленными сайтиками. Поэтому и среди фронтендеров эта тема не особо известна. Но все кому надо, прекрасно в курсе вопроса и с удовольствием используют эту технологию.