LINUX.ORG.RU

Прогрессивные разработки GUI

 , , ,


2

4

Может кто-то встречал необычные идеи, концептуальыне проекты, или просто какие-то передовые и непопулярные модификации имеющихся инструментов разработки интерфейсов?

Интерфейсы довольно длительное время были в плену у объектно-ориентированного рака, где у вас есть одна кнопка, одна мышка, и вам нужно нажать мышкой на кнопку — отсюда было шизофреническое разделение интерфейса на независимые сущности, отсюда главный цикл, который обрабатывает эту самую одну мышку (либо кнопку клавиатуры), и объекты GUI как состояния кусков экрана. В Smalltalk/VisualWorks отдельные объекты были более значимо выделены (с возможностью сохранять состояния отдельных объектов), а в современных десктопных GUI весь гуй является одним состоянием, и очередь сообщений у него тоже одна.

Одними из первых от этой модели отказались игроделы, которые смекнули, что рисовать интерфейс можно независимо от расчета логики игры и реакции на ввод. Примерно в этом состоянии и находится индустрия сейчас, как тот же андроид Lollipop, на который неспешно перекатываются девайсы.

Самую-присамую писечеку из рядов массового софтопрома разрабатывает гугл в своем хроме:

https://www.chromium.org/developers/design-documents/compositor-thread-archit...

В хроме поток логики с жавоскриптом остается за главного, однако, часть логики отрисовки блоков перенесена в отдельный поток композитора — за счет чего веб-страница выглядит относительно живо при висящем жавоскрипте. Само наложение текстур блоков с CSS-рюшечками, естественно, делаются уже на видеокарте в отдельном потоке, а композитор только отвечает за «быстрые» прокрутку и изменение размеров. Быстрые — то есть описанных через базовые поддерживаемые концепции HTML/CSS и без задействования JS.

Но даже этого недостаточно для того, чтобы приложения на электроне перестали быть тормозным и жрущим оперативу калом. Но достаточно, чтобы сравниться с приложениями на Java. Это забавно выглядит в 2020 году, когда производительность процессоров растет медленнее, чем растет тормознутость интерфейсов. Сижу я тут, играю в Deus Ex: Mankind Divided, и думаю: а может, и правда, в 2029 году «прогресс» дойдет до того, что интерфейс для ввода четырех циферок будет открываться-закрываться по пять секунд, как в этой игре? И выключатели на тач скринах, которые работают только на «вкл-выкл» — я ванговал в соседнем треде, что на будущих девайсах для прогрессивной молодежи должна быть только одна кнопка.

Объективно, если брать современный GUI iOS/Android, то это упрощение по сравнению с многозадачными интерфейсами десктопов: пониженные требования многозадачности, пониженные требования к отзывчивости, набор доступных действий неочевиден, что идет против концепции GUI «я должен найти все фичи программы просто гуляя по менюшкам» — последняя проблема уже имеет варианты решения в виде Pie/Marking Menus. Да, это частично оправдано малым экраном. Да, эти проблемы со временем можно будет частично решить (если тенденция ухудшения не перевесит тендинцию улучшения). Но в целом, с позиции разработки, программы для тачфонов по прежнему пишутся в стиле однопоточного цикла обработки сообщений, просто сообщения стали несколько другими.

Меня пока что манит идея «скриптовухой» выкидывать описание GUI в какую-то структуру в разделяемой памяти, чтобы потом по этой структуре происходила отрисовка интерфейса, причем, той же «сприптовухой», но параллельно работающей. Вплоть до того, что с разделяемой структурой интерфейса будет работать несколько программ, используя транзакции. Например, у нас есть программа основной логики интерфейса, которая обрабатывает окошечки/кнопочки/поля ввода, и есть задачи фонового скачивания файлов. Фоновое скачивание живет само по себе, обновляет свои специфичные элементы GUI, при этом большую часть времени не взаимодействует с потоком логики, а только взаимодействует с отрисовщиком/композитором/taskname через разделяемую память.

★★★★

Ответ на: комментарий от byko3y

Non-GUI потоки могут работать на любых механизмах, не обязательно делать это через очереди сообщений.

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

Даже очень опытные и квалифицированные программисты время от времени обсираются, выдавая дедлоки/сегфолты/гонки на ровном месте.

X512 ★★★★★
()
Ответ на: комментарий от X512

Запускал X.Org с выключенным композитором и всё летает.

И интерфейс «зависшей» программы начинает «смазываться» как в windows 98 угу.

anonymous
()
Ответ на: комментарий от X512

Запускал X.Org с выключенным композитором и всё летает

Про Haiku ничего не скажу, потому что никогда ее не видел. Но иксы без аппаратного ускорения на достаточно большом разрешении тягают окна очень неторопливо.

2D ускорение уже устарело и его поддержку выпилили из видеокарт. Сейчас любое ускорение работает на базе 3D ускорения

Так я не спорю. Но в иксах нету 3D ускорения, там только 2D, а как уже оно реализовано в интерфейсах к железу — не важно, важно только что это самое железо должно быть.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Но иксы без аппаратного ускорения на достаточно большом разрешении тягают окна очень неторопливо.

Возможно кривая архитектура с работой напрямую на фреймбуфере. Чтение фреймбуфера (например для копирования содержимого при перемещении окна) очень медленное поэтому нужно использовать задний буфер в RAM.

Но в иксах нету 3D ускорения, там только 2D

Оно через OpenGL работает (Glamor).

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от pon4ik

для какой сущности ALPC является интерфейсом?

ALPC является базовым механизмом межпроцессового вызова, оно не является интерфейсом ни к чему.

Какие ключевые отличия между QApplication и boost::asio::io_service?

Различие в том, что boost::asio::io_service почти никому не нужно.

byko3y ★★★★
() автор топика
Ответ на: комментарий от X512

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

Неконтролируемая асинхронная очередь сообщений решает только малую часть проблем. Для решения остальных нужно как минимум вводить приоритеты, отмену, зависимости, механизмы передачи и высвобождения данных, и прочие радости.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

ALPC является базовым механизмом межпроцессового вызова, оно не является интерфейсом ни к чему.

Вызовы куда кладутся? В очередь. В Haiku через аналогичный механизм все GUI сообщения работают.

X512 ★★★★★
()
Ответ на: комментарий от byko3y

Для решения остальных нужно как минимум вводить приоритеты, отмену, зависимости, механизмы передачи и высвобождения данных

Откуда вдруг всё это понадобилось? По крайней мере для индикации загрузки, о которой говорилось ранее, это не нужно.

X512 ★★★★★
()
Ответ на: комментарий от X512

Возможно кривая архитектура с работой напрямую на фреймбуфере. Чтение фреймбуфера (например для копирования содержимого при перемещении окна) очень медленное поэтому нужно использовать задний буфер в RAM

В винде та же история, потому что для перемещения окна нужно скопировать область самого окна и перерисовать область за окном. И для достаточно большого окна делать это 60 раз в секунду на одном процессоре уже не получается.

Оно через OpenGL работает (Glamor)

О чем я и пишу: иксы умеют только в 2D, а реализации уже не все ли равно во что там транслируют, хоть в вызовы функций ASIC-а.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

В винде та же история

В Haiku с самого начала всё сделали правильно и всё быстро работает без аппаратного ускорения.

И для достаточно большого окна делать это 60 раз в секунду на одном процессоре уже не получается.

Я мерил что программную перезапись всего экрана 1920x1800 можно делать несколько тысяч раз в секунду.

X512 ★★★★★
()
Ответ на: комментарий от X512

Вызовы куда кладутся? В очередь. В Haiku через аналогичный механизм все GUI сообщения работают

Это деталь реализации, которая не обязаны быть именно таковой. Более того, там есть более одной очереди, для работы с пулом рабочих потоков сервера или конкретным целевым потоком.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

которая не обязаны быть именно таковой

Обязана. Если запросы придут не в том порядке или не придут, то всё сломается.

X512 ★★★★★
()
Ответ на: комментарий от X512

Я мерил что программную перезапись всего экрана 1920x1800 можно делать несколько тысяч раз в секунду

При 24 битах это 10 Мб буфер экрана. Самый-присамый-присамый оптимальный код современного процессора на одно ядре может обработать примерно 10-15 Гб/с памяти на чтение. То есть, тысячу экранов в секунду. Скопировать может дай бог если 500. Если же у тебя есть какая-то логика обработки, да плюс еще и переключения контекстов с прерываниями (у нас же многозадачная система), то вот ты и получаешь свои законные 10 кадров в секунду.

byko3y ★★★★
() автор топика
Ответ на: комментарий от X512

Обязана. Если запросы придут не в том порядке или не придут, то всё сломается

Порядок должен соблюдаться в рамках одного клиента, остальное, как правило, не важно.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

ALPC является базовым механизмом межпроцессового вызова, оно не является интерфейсом ни к чему.

Аааа, так межпроцессное взаимодействие работает с помощью волшебных гномиков значит. Ясно, понятно. Магия во все поля.

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Аааа, так межпроцессное взаимодействие работает с помощью волшебных гномиков значит. Ясно, понятно. Магия во все поля

Все базовые механизмы работы ядра построены на волшебных гномиках, и периодически одних гномиков меняют на других, не изменяя интерфейса.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Различие в том, что boost::asio::io_service почти никому не нужно.

Глубокое наблюдение, если ты и правда про то, что это по-сути своей одно и тоже.

pon4ik ★★★★★
()
Ответ на: комментарий от t184256

как тот же андроид Lollipop, на который неспешно перекатываются девайсы.

18.12.2020

Ты хочешь сказать, что фичи лолипопа остались во всех последующих версиях андроида? Хорошо, я просто ненавижу андроид, потому не особо вдавался в детали.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

То, что поток разгребающий очередь не дали писать макаке, не значит, что вовлечена магия. А уж реализации очередей им уже давно не дают на откуп.

pon4ik ★★★★★
()
Ответ на: комментарий от byko3y

Если же у тебя есть какая-то логика обработки, да плюс еще и переключения контекстов с прерываниями (у нас же многозадачная система), то вот ты и получаешь свои законные 10 кадров в секунду.

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

X512 ★★★★★
()
Ответ на: комментарий от byko3y

ALPC

Вот кстати пример использования ALPC с необходимыми объявлениями недокументированных функций: https://github.com/DownWithUp/ALPC-Example. Лучше ознакомится как это всё на самом деле работает а не рассуждать про гномиков.

X512 ★★★★★
()
Ответ на: комментарий от pon4ik

То, что поток разгребающий очередь не дали писать макаке, не значит, что вовлечена магия. А уж реализации очередей им уже давно не дают на откуп

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от X512

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от pon4ik

Чисто до тех пор, пока ты не разрешишь окнам накладываться друг на друга

При чем тут ALPC к окнам? Это сервисный канал, который чаще используется для связи служб и драйверов.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Я считаю из расчета на многозадачную систему с защищенным режимом, у которой передача байтов ведется самыми разными способами и в отрисовке участвует несколько процессов.

В системах без композитинга отрисовка происходит на стороне GUI сервера, которому напрямую доступен фреймбуфер. Программы присылают ему векторные команды рисования. Команды группируются в пакеты чтобы сократить число переключений контекста. В Haiku это хорошо сделано и в отличии от X11 и GDI есть современные векторные команды со сглаживанием, прозрачностью и градиентами. Графика рисуется через AGG.

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

В системах с кривой архитектурой может и так, но в Haiku всё быстро работает.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

В Haiku это хорошо сделано и в отличии от X11 и GDI есть современные векторные команды со сглаживанием, прозрачностью и градиентами. Графика рисуется через AGG

А, то есть вот оно как: давайте переписывать все приложения, потому что у нас тут новая ось вышла.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

давайте переписывать все приложения, потому что у нас тут новая ось вышла.

Я лишь про то, что программная графика быстро работает если захотеть. Быстрее многих современных приложений с аппаратной графикой. Кривой код всегда будет тормозить и никакое ускорение не поможет.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

Я лишь про то, что программная графика быстро работает если захотеть. Быстрее многих современных приложений с аппаратной графикой. Кривой код всегда будет тормозить и никакое ускорение не поможет

Ты преувеличиваешь тормознутость конкретно графики у «современных приложений с аппаратной графикой». Тормозит там логика, тормозят отдельные ресурсоемкие эффекты, или какой-нибудь перерасчет макета при изменении размера, но графика, как правило, не является чем-то ресурсоемким. Она просто не является оптимизированной по ЦПУ, поскольку последние лет так двадцать на всех компах есть видеокарта, а последние лет десять она встраивается в процессор. Это как адаптировать приложения под COM порт, когда на некоторых системниках уже и порта этого нету.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Я просто представляю себе как я вместо того как обычно молотить на сях многомегабайтные json’ы и xml’ки собираю собрание и говорю «пасаны, не могу так молотить, давайте по 10 элементов обмениваться, сервак не вывозит».

PPP328 ★★★★★
()
Ответ на: комментарий от byko3y

Ну то есть почему не взлетела та же жава на GUI? Потому же не взлетит и Go — потому что чертовый сборщик мусора создает неопределенную задержку ввода.

Нет не из-за этого. А из-за лишней прослойки - JVM, которую не поставишь на каждую машину.

anonymous
()
Ответ на: комментарий от X512

Для каждого визуального объекта (MovieClip) хранится векторная картинка того что в него нарисовано и растровый кеш. Теоретически картинку можно рисовать полностью независимо от логики и при зависшем скрипте.

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

XoFfiCEr ★★☆☆
()
Ответ на: комментарий от XoFfiCEr

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

Как это не было? Весь Flash основан на векторной графике. Есть векторные команды для рисования на MovieClip из ActionScript.

X512 ★★★★★
()
Ответ на: комментарий от PPP328

Я просто представляю себе как я вместо того как обычно молотить на сях многомегабайтные json’ы и xml’ки собираю собрание и говорю «пасаны, не могу так молотить, давайте по 10 элементов обмениваться, сервак не вывозит»

Ты знаешь, я анализировал архитектуру моего нынешнего проекта на рабстве, и пришел к выводу, что таки нужно городить на сях логику БД, которая бы с минимальными накладными расходами и без ACID сохраняла сложноиерархичные данные гибкой структуры, только не в кривом JSON, который задолбаешься парсить, а в структурированном формате, в котором можно было бы делать поиск по подстроке сквозь весь массив данных, что было бы достаточно эффективно при достаточно компактном формате хранения этих данных за счет попадания в кэши. Таким образом производительность сервера определяется не дисками, а оперативной памятью.

Что-то очень близкое к Redis, только в самом сервере БД должна тусить достаточно сложная логика запроса данных, и эта логика должна уметь прочесывать десятки мегабайт данных за доли секунды. А это проблематично, потому что сраный Си может легко уроронить сервер, или просто побить данные ни с того, ни с сего. А безопасных и быстрых языков у нас нынче не так много.

byko3y ★★★★
() автор топика
Ответ на: комментарий от anonymous

Нет не из-за этого. А из-за лишней прослойки - JVM, которую не поставишь на каждую машину

Как раз смысл JVM заключается в том, что его можно поставить на любую машину и использовать для запуска всех программ для JVM.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Как раз смысл JVM заключается в том, что его можно поставить на любую машину и использовать для запуска всех программ для JVM

Это в теории. А в реале много ли ты знаешь простых юзеров которые ставят JVM на свои машины?

anonymous
()
Ответ на: комментарий от X512

Для него Го не подходит, потому что

чертовый сборщик мусора создает неопределенную задержку ввода

anonymous
()
Ответ на: комментарий от byko3y

или просто побить данные ни с того, ни с сего.

Не нужно на нем макачить просто. Интересно, почему у меня демоны на сях работают на 2500+ узлах и не роняют ни их ни данные?

PPP328 ★★★★★
()
Ответ на: комментарий от anonymous

Для него Го не подходит

Он же логику БД писать собрался:

Что-то очень близкое к Redis, только в самом сервере БД должна тусить достаточно сложная логика запроса данных, и эта логика должна уметь прочесывать десятки мегабайт данных за доли секунды.

X512 ★★★★★
()
Ответ на: комментарий от anonymous

Да и заметь, что на .NET, который двигает MS, никакой гуй не тормозит, а ведь там тоже GC

Я знаю, и я это регулярно пишу. У .NET довольно развитые нативные либы, из-за чего он плохо портируется. А сам гуй писан на архитектуре логика+рендер, что близко к флешу. GC, на самом деле, тормозит, но благодаря такой архитектуре это незаметно.

byko3y ★★★★
() автор топика
Ответ на: комментарий от X512

А безопасных и быстрых языков у нас нынче не так много.

Rust, Go

Да. И кто будет на них писать?

byko3y ★★★★
() автор топика
Ответ на: комментарий от anonymous

Для него Го не подходит, потому что

чертовый сборщик мусора создает неопределенную задержку ввода

В том контексте разговор был про сервер.

byko3y ★★★★
() автор топика
Ответ на: комментарий от PPP328

Не нужно на нем макачить просто. Интересно, почему у меня демоны на сях работают на 2500+ узлах и не роняют ни их ни данные?

Мне сложно отвечать про софтину, про которую я не знаю ничего кроме того, что она написана на сях. Ответы могут быть:

— потому что она ничего не делает
— потому что большая часть ее написана не тобой

и так далее.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

— потому что она ничего не делает

Она ежесекундно обслуживает оборудование в кинотеатрах стоимостью в несколько миллионов рублей каждое.

— потому что большая часть ее написана не тобой

Как раз таки большая часть написана мной. А когда нечего сказать - переходи на личности, ага.

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

PPP328 ★★★★★
()
Ответ на: комментарий от X512

нет он не основан на векторной графике он основан на растровой. Что значит векторные комманды? Любая картинка была объектом, символом как то так оно называлось. Рисование там могло быть векторное не спорю а вот то что загружено как растровая картинка то и использовалось как растр, то есть никакой векторизации не было.

XoFfiCEr ★★☆☆
()
Последнее исправление: XoFfiCEr (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.