LINUX.ORG.RU

Набросать сценарий использования

 ,


0

1

Привет.

Задумал примерно следующее: консольное приложение, окошки открываются как вспомогательный инструмент (может быть много, а может ни одного), каждое окошко в своём потоке. Так понимаю, что пара gtk_application_new() g_application_run() из hello worlda не подходит в таком случае, почитываю мануал, но что-то пока из него не ясно. Может кто чего дельного подскажет и буду читать не всё подряд, а прицельно. Нужно примерно так:

int main() {
   // создаются потоки с окнами window_fn()
   ...
}

void window_fn() {
   // создаю и показываю окошко
   while(true) {
      // обработка gtk сообщений

      // обработка моей собственной очереди сообщений для потока
   }
}

т.е. интересует примерный каркас window_fn(), какое gtk api дёргать для создания окна и однократного запуска оконной процедуры.

★★
Ответ на: комментарий от i-rinat

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

Знаем. В диспетчере задач показывается число потоков:

https://imgur.com/a/TiPJ5Pq

На Qt, просто окошко и пару QPushButton в QBoxLayout, сам я никакие потоки не создавал…

fsb4000 ★★★★★
()
Ответ на: комментарий от i-rinat

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

Рисовать напрямую в задний буфер нельзя, надо выделить новый растровый буфер и вызвать BView::DrawBitmap. Так как клиент удалённого рабочего стола не может использовать общую память, содержимое картинки передаётся по сокету.

Повторяю в третий раз.

Вам известно понятие регионов? Регионы - это набор отсортированных не пересекающихся прямоугольников с которыми можно выполнять булевы операции и которые используются для отсечения (clipping) отрисовки. У каждого окна есть регион, которым отсекаются все графические команды, приходящие в него. Если одно окно заслонено другим, то от региона нижнего окна вычитается регион верхнего окна. В результате регионы окон не пересекаются и окна могут рисовать параллельно друг от друга. Если переднее окно переместить, то регион заднего окна может расшириться и новая часть будет перерисована.

Картинка с пояснением: https://imgur.com/a/tWRVUAH.

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

Знаем. В диспетчере задач показывается число потоков:

Это потоки пула потоков, который был недавно введён. В Windows XP в приложении только один поток, если вручную не создавать новых потоков.

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

OK, понятно. Ты, пожалуй, единственный, кто такую терминологию использует.

HTTP или NFS серверы бывают в ядре, почему бы и GUI серверу не быть в ядре?

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

Рисовать напрямую в задний буфер нельзя

Эта фраза прямо противоречит фразе «Буфер с векторными командами тоже так умеет.»

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

И в тот момент, когда перемещение одного окна (1) открывает новые части другого (2), приложение, занимающееся окном 2, должно отрисовать содержимое открывшейся области. Если нет готовой картинки, которую можно просто блитнуть из буферизованной картинки, рисование запросто может занять несколько кадров. И в это время пользователю будут видны артефакты. Сначала там будет старое содержимое окна 1. Потом оно будет перерисовано. Это видно на видео с презентацией BeOS. А вот если буфер есть, всё сводится к копированию прямоугольных областей. Эта базовая операция 2d-ускорения.

Я настолько непонятно объясняю? Это всё размен потребления памяти на артефакты отрисовки. Не вижу тут никаких преимуществ. Просто каждый выбирает, что для него важно и принимает решения на этой основе. Выбираешь экономию памяти? Платишь повышенным потреблением CPU и артефактами отрисовки. Выбираешь визуальное представление? Платишь потреблением памяти и повышенным потреблением GPU. Сразу всё получить не выйдет.

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

HTTP или NFS серверы бывают в ядре, почему бы и GUI серверу не быть в ядре?

Вполне могут. Только вот ты же просто ядерную часть реализации аналога pthread_cond_wait() сервером называешь. Никогда не видел, чтобы такую терминологию использовали.

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

Эта фраза прямо противоречит фразе «Буфер с векторными командами тоже так умеет.»

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

рисование запросто может занять несколько кадров. И в это время пользователю будут видны артефакты.

Да, при перемещении переднего окна, на заднем окне будут видны артефакты если заднее окно рисуется медленно. По идее вместо отпечатывания должен рисоваться фоновый цвет отображений (это менее заметно, чем отпечатывание), то это сейчас неправильно работает и отключено, в BeOS работает. При обновлении окна (BView::Invalidate) за счёт заднего буфера, мерцания и артефактов не будет. Так как окна обновляются чаще, чем перемещаются, артефакты при перемещении не так страшны и они возникают только в медленных программах.

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

Только вот ты же просто ядерную часть реализации аналога pthread_cond_wait() сервером называешь.

Ладно про GetMessage. CreateWindow, SetWindowPos, BitBlt можно считать командами GUI сервера? В X.Org и app_server (GUI сервер в Haiku) есть аналоги.

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

Просто использовать Qt как белые люди.

Негры использующие qt никогда белыми людьми не станут.

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

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

можно считать командами GUI сервера?

Если это вопрос про моё мнение (зачем?), то вряд ли. Судя по моим поверхностным знаниям, в Windows нет чётко выделенного GUI-сервера. Нет сервера — нет команд сервера.

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