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 через разделяемую память.

★★★★

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

Это информация, актуальная на момент windows 98

У меня Windows 7.0, которая /без сарказма/ великолепно работает, кроме выше описанного варианта работы.
Интерфейс становится плохо отзывчивым, в остальном все летает!
А куда ей деваться если все абсолютно логи отключены, сервисы работают лишь самые необходимые, …
Да и Visual Studio - летает!

Владимир

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

Так-то с твоей позиции можно сказать «нахер нам GUI — можно же программировать коробки из переключателей и светодиодов». А вот нельзя

Так-то с твоей позиции можно сказать

Нельзя

Смысл развития интерфейсов заключался в том, чтобы сделать его более естественным и незаметным. Если интерфейс становится испытанием, то это плохой интерфейс. Современные интерфейсы тачфонов прокатывают, потому что ими в основном пользуются школьники и домохозяйки, которые будут жрать также ранеток и сериал «дикая роза»:

95% населения — идиоты

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

https://habr.com/en/post/403307/

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

Меня пока что манит идея «скриптовухой» выкидывать описание GUI в какую-то структуру в разделяемой памяти, чтобы …

Ты многопоток в питоне сначала доделал бы, а то бросил на полпути. Конечно оно никому не нужно в таком виде

Что не нужно? То, что я даже не публиковал? Я бы не сказал, что бросил — у меня тут родственник заболел, а я на фоне стресса временно забросил спорт, набрал кг веса и словил гастрит от плохого питания. Теперь отхожу, вроде более-менее стабилизировалось самочувствие.

Во-вторых, это не многопоток, а многозадачность, поскольку многоинтерпретаторы изолированы друг от друга. Проблема такого подхода заключается в том, что ты не можешь просто вызвать из одного интерпретатора функцию в контексте другого интерпретатора — как делает multiprocessing, например, и как у него отвратительно это получается делать. Мой подход на разделяемой памяти и примитивах синхронизации (вместо RPC) чисто теоретически лучше, поскольку провоцирует написание в асинхронном стиле с уменьшением связанности. Но чисто практически под эту хрень мало готовых решений, особенно для GUI. Классические тулкиты, вроде GTK/Qt, не имеют модели, в них GUI является цельносвязанным состоянием и переход в другое состояние осуществляется строго синхронно.

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

Удваиваю этого господина

Если ты понял, что он написал — просьба пояснить мне.

Любой эффективный GUI это абсолютно такой же I/O серверок как nginx

Как только nginx научится выполнять логику, а не только выполнять stateless трансляцию запросов — приходи.

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

Там устройства это файлы, пользователь это файл, и форма это файл

Это прокатывало тогда, когда сущности были примитивны. А что ты собрался select-ить по дескриптору пользователя или формы в 2020 году?

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

В статье ни тестов, ни демонстрации решения каких-либо проблем(в чём автор сам признавался). Не важно, что именно там было

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

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

Да любая реализация GUI приложения современного в своей основе содержит такой асинхронный сервер, либо прокси

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

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

Ты скажи чего ты там хочешь конкретно? Чтобы не было никакой возможности засунуть дополнительную логику в гуёвый поток даже если программист очень этого хочет?

Я хочу тормознутыми инструментами сделать нетормознутый GUI. Так, чтобы на его создание не потребовались миллионы человекочасов, как в случае Chromium. Элементарный пример: пользователь жмет кнопку, но логика отрабатывает через пару секунд. Однако, при этом гуй прорисовывает прогресс, хотя бы отображает корректное изменение формы кнопки после нажатия, не говоря уже об индикации прогресса думания.

Ну то есть почему не взлетела та же жава на GUI? Потому же не взлетит и Go — потому что чертовый сборщик мусора создает неопределенную задержку ввода. из-за чего пользователь начинает кричать «у меня софтина сломалась» и тыкать беспорядочно в кнопки, а потом не понимать, что произошло.

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

Мьсе путает i/o устройства для типового гуи приложения (иксы, другие реализации) и само приложение.

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

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

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

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

Tcl/Tk уже предлагали?

Да, прикольный инструмент, но только если из него убрать этот уродливый построенный на строках тикль.

пытаемся натянуть прототип гуйни с Tk на вебню. Это ахтунг, товарищи. Вебмакакам нужно стаж считать год за 3. У них работа в экстремальных условиях типа крайнего севера

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

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

А что ты собрался select-ить по дескриптору пользователя или формы в 2020 году?

Как что? Событие ввода/вывода.

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

Раньше можно было смотреть таблицы на тысячи элементов, а сейчас интернет магазины показывают по 20 элементов за раз потому что этот кал иначе жрет 3 гига

Знаешь, я как-то даже не пробовал показывать тысячи элементов. Скорее потому, что сервак на пыхе сдохнет такое число данных формировать,

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

Ты вот кажется пытаешься что-то противопоставить, однако противопоставлять нечего - объектный подход к GUI и организация главного цикла с обработкой сообщений не менялся с момента появляния этого самого GUI, и он одинаковый что в DOSовском софте 30летней давности, что в современном хроме, игрушках и андроиде

В досовских софтинах частенько гуй был не объектным, так тчо не надо мне тут. Этот рак распространился по конкретному пути Xerox->NeXTSTEP->Windows, после чего началась пандемия.

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

Это «нормально», когда неважно, что делает игрок, что видит игрок, что делают противники, и вообще, сама игра не важна - видеофильм с опциональной интерактивностью

Starcraft, WoW, CS, Dota — ага.

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

Если ты понял, что он написал — просьба пояснить мне.

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

Как только nginx научится выполнять логику, а не только выполнять stateless трансляцию запросов — приходи.

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

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

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

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

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

Так я ничего не понял, у нас ООП рак? Но Smaltalk тоже ООП! Или просто системы так делают?

В Smalltalk ООП было оправдано архитектурой. В последующих попытках подражания — уже нет, это были аборигены, раскрашенные краской в одежду солдат США, которые маршируют вокург соломенных самолетов в надежде, что к этому их проекту тоже потянутся пользователи и разработчики.

Справедливости ради, разрабы винды таки сделали окна независимыми, с возможностью составлять окошко из окон разных приложений. Правда, писать такие приложения, по крайней мере инструментами того времени, было неподъемно сложно.

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

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

Кто мешает запустить отдельную очередь сообщений в другом потоке и обрабатывать логику там? Есть готовые фреймворки для этого.

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

Ему не нравится, что многопоточность не пихают куда попало. И вообще почему только многопоточность? Надо пихать многопроцессность, а обмен сообщениями только через ядерный IPC (однопоточный, «но это другое»)

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

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

Какие были проблемы при скачке файлов?

Либо не отображается прогресс, либо отображение прогресса мешает главному приложению.

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

с околонулевой задержкой реакции на ввод.

Для низкой задержки реакции лучше выкинуть видеокарту и рисовать на CPU в стиле Windows 95. Всякий обмен CPU <-> GPU и синхронизация создаёт дополнительные тормоза.

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

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

Ну так объясни мне, почему даже жирные приложения на жаве 90-х годов кушали пару десятков мегбайт памяти, а электрон с чистым листом начинается от сотки.

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

Либо не отображается прогресс, либо отображение прогресса мешает главному приложению.

Научитесь уже работать с потоками, везде прогресс нормально показывается и ничего не висит. Какая-то особая архитектура GUI тут не поможет, оно тут вообще не при чём.

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

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

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

А дело-то в специфической на грани осознавания реакции системы — примерно то, о чем недавно говорил Arkanoid, только про мобильные телефоны.

Леонид Каганов, 2008 год (за прошедшие годы линукс, к сожалению, успешно догнал винду по этому показателю)

Эх, в 2008 году и я этих людей читал.

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

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

Мне пофигу, у меня нет готовых путей решения ни для одного варианта.

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

В том же Qt есть отличная абстракция из сигналов и слотов

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

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

Как что? Событие ввода/вывода

Какие события? Мышь, клава, вставка USB устройства, сигнал с микрофона? Сейчас ввода от пользователя стало заметно больше, чем просто одна клавиатура, потому и каналов стало больше.

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

и, тем не менее, софтины на Qt продолжают тупить и крашиться.

Надо поставить watchdog на GUI поток и вызывать abort() при превышении лимита времени (0.2 секунды). И все быстро научатся делать хороший софт.

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

Не, эту ветку я бы свернул, т.к. мне прям ну лень рассказывать раз у тебя фантазии не хватает, отойти от понимания абстракции устройство ввода как «мышь» или «usb».

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

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

Используется жесткое квантование с опросом, которое не совсем то же самое, что цикл обработки событий в GUI/nginx. Хотя там также используется обработка несколькими независимыми процессорами, что находится еще дальше от GUI/nginx.

Но, тот же nginx умеет statefull обработку запросов, был недавно про это тред на лоре, второй раз лень искать

Да, и он становится таким же дерьмом, как Apache. Потому что в логике весь затык, нет никакого достижения в быстрой трансляции запросов. В данном случае nginx превозмогал только кривость linux/posix. В той же винде IO Completion Port были начиная с NT с поддержкой многопоточной обработки запросов, потому проблемы. которую решал nginx, на винде в принципе не существовало.

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

Как вы себе представляете многопоточную очередь сообщений? Для обработки ввода важен порядок операций

Очередь сообщений окна в винде представляет собой намного более обширный механизм, чем просто пользовательский ввод. Через него же делает некоторое IPC, получаются различные сигналы от системы, в том числе перерисовки и изменения положения окон. Но в итоге все эти механизмы, да еще и для разных окон, проходят через единственное бутылочное горлышко цикла обработки сообщений главного окна приложения. Да-да, даже для разных окон перерисовка отправляется в единую главную очередь потока GUI.

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

Кто мешает запустить отдельную очередь сообщений в другом потоке и обрабатывать логику там? Есть готовые фреймворки для этого

Какие? Потому что я не совсем понимаю этого подхода.

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

Да вот нет, используются обычные циклы обработки событий, на обычных очередях, и всем хватает. Ладно, они конечно не совсем обычные, там зачастую используется оптимистичная синхронизация и прочие приёмы которые нет смысла использовать в системах, у которых сами железки имеют время отклика в лучшем случае в сотни микросекунд(и то это скорее всего о5 же сетевухи).

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

Для низкой задержки реакции лучше выкинуть видеокарту и рисовать на CPU в стиле Windows 95. Всякий обмен CPU <-> GPU и синхронизация создаёт дополнительные тормоза

Запусти любую современную GUI-based систему (win/lin/mac) на VGA с полностью отключенным аппаратным ускорением (в том числе 2d), и больше такого не пиши.

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

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

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

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

Да-да, даже для разных окон перерисовка отправляется в единую главную очередь потока GUI.

В WinApi можно создать несколько GUI потоков. Поток окна определяется по потоку, вызвавшему CreateWindow. Можно хоть для каждой кнопки свой поток сделать.

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

Не, эту ветку я бы свернул, т.к. мне прям ну лень рассказывать раз у тебя фантазии не хватает, отойти от понимания абстракции устройство ввода как «мышь» или «usb»

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

https://ru.wikipedia.org/wiki/World_of_Goo

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

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

Какие?

Да хоть тот же WinApi: сделать невидимое окно в отдельном потоке и отсылать ему сообщения о запуске логики. Поток логики может отсылать сообщения окну для обновления статуса. В Qt, Haiku API есть аналогичное. Никаких семафоров и прочих примитивов синхронизации не надо, только сообщения.

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

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

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

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

В WinApi можно создать несколько GUI потоков. Поток окна определяется по потоку, вызвавшему CreateWindow. Можно хоть для каждой кнопки свой поток сделать

Можно несколько потоков. Но нельзя одну очередь читать разными потоками, и один поток имеет одну очередь.

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

Это, я тебя разочарую, но Apache Spark и Hadoop работают с питоном. В многозадачность там упороться можно, даже не обязательно на 1 машине считать, можно на 100500.

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

Запусти любую современную GUI-based систему (win/lin/mac) на VGA с полностью отключенным аппаратным ускорением (в том числе 2d), и больше такого не пиши.

Пользуюсь Haiku в которой вообще нет никакого ускорения и всё рисуется CPU на фреймбуфере. Всё работает быстрее и отзывчивее чем в Windows и других системах с аппаратным ускорением. Аппаратное ускорение в GUI нужно только для спецэффектов и тяжёлых стилей.

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

в том числе 2d

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

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

Да хоть тот же WinApi: сделать невидимое окно в отдельном потоке и отсылать ему сообщения о запуске логики

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

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

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

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

Но нельзя одну очередь читать разными потоками

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

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

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

Погоди, погоди, дай я угадаю.

Уж не очередь ли?

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

pon4ik ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.