LINUX.ORG.RU

Ui

 ,


0

2

Приветствую.

Решил подкинуть ещё масла в огонь в битве x против woyland. Мне кажется, что обмен данными через shared memmory между окнами и менеджером окон, тоже имеет права на жизнь (должно быть быстрее и проще) и сейчас провожу изыскания на предмет с чего начать. Чат гпт после долгого распрашивания предложил хранит окна в b+ дереве, может глюканул, а может в инете есть где-то материал по этому поводу (я не нашел). У кого нибудь есть опыт по написанию UI. Может в игрушках делали. Мой сводится к рисованию окошек в TUI, к базе данных ещё на паскале. Благодарю.

Мне кажется, что обмен данными через shared memmory между окнами и менеджером окон

а они по твоему по интернету данными обмениваются? или смсками?

в компе вообще все обмены идут через память.

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

unix сокеты(если это о них) это и есть разделяемая память под капотом

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

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

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

По сокетам как-бы, иначе бы по сети не работали ли бы. Это значит всю модель osi проходят, что imho, overhead и можно выкинуть.

Sergeyka
() автор топика
Последнее исправление: Sergeyka (всего исправлений: 3)
Ответ на: комментарий от anonymous

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

Sergeyka
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

Тапки обойти нам поможет гпт.

Если так:

Уважаемые коллеги,

Я работаю над разработкой программы, использующей KMS/DRM, и планирую добавить несколько кнопок в управление. Однако возникла проблема: текущие реализации X и Wayland используют сокеты для передачи данных, что создает дополнительный оверхед из-за задержек, связанных с обработкой данных, и возможно, других непредвиденных факторов.

В связи с этим, я рассматриваю возможность обмена данными через общую память (shared memory). У кого-то из вас есть комментарии по этому поводу? Какие известные подводные камни могут возникнуть при реализации такого подхода? Буду признателен за любой опыт или советы.

С уважением,

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

Всё верно тебе написали, unix сокеты это и есть буферы (очереди) в памяти, оверхэд минимальный. Больше подводных камней найдёшь как раз со своей реализацией (де)сериализации и синхронизации. Экономия на спичках.

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

Автору стоило уточнить, какими именно данными он собирается обмениваться. Если буфером кадра 4K@60, то выигрыш от SHM может быть в избежании копирования блоков памяти. Если же сообщениями <кнопка нажата>, то выигрывать там нечего.

anonymous
()