2014-09-23 2 views
1

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

Итак, я решил, что он должен поддерживать специальные процессы для приложений, но это подводит меня к вопросу, и именно так я могу сшить выходы разных процессов вместе и высокопроизводительным образом. Копирование данных с GPU на CPU для совместного использования в системной памяти просто не является вариантом. Из OpenGL parallel FAQ стало ясно, что использование одного контекста из нескольких процессов не возможно, если оно не является косвенным, что приводит к очень низкой производительности.

Итак, как работают существующие оконные менеджеры? Естественно, я не ожидаю никаких подробностей на низком уровне, просто общий обзор концепции.

+0

Если ваша платформа выставляет ручки на поверхности, в которые она втягивается, вы можете это сделать. WDDM (Windows Vista +) предлагает вещи, называемые общими дескрипторами, которые служат этой цели, но получение доступа к одному для произвольного процесса - это не то, что вы обычно можете делать как конечный пользователь (лучшее, что предлагает публичный API в этом смысле миниатюра DWM "). На других платформах гораздо проще свернуть собственный диспетчер окон компоновки, особенно Linux. * На какой платформе вы интересуетесь? * –

+0

К сожалению, нет стандартного и портативного решения. Оконные составители прибегают к использованию специальных расширений для поставщиков, и часто даже не напрямую. Например, Wayland полагается на EGL для этого. Это связано с тем, что рендеринг исторически очень фрагментирован, у вас есть программный рендеринг, у вас есть аппаратное ускорение Direct2D, Direct3D, OpenGL ... Вот почему совместное использование буфера должно нарушать разрывы между различными технологиями. Я предполагаю, что возможность совместного использования буферов между различными процессами для OpenGL по стандарту будет довольно сладкой, но в ближайшее время нет никаких признаков этого события ... – dtech

+0

@ AndonM.Coleman - Я надеялся на что-то более портативное, чтобы оно могло работать вершина существующих оконных менеджеров для окон, linux и android ... – 2014-09-23 16:47:18

ответ

1

Итак, как работают существующие оконные менеджеры? Естественно, я не ожидаю никаких подробностей на низком уровне, просто общий обзор концепции.

В X11 есть расширения X11 GLX_ARB_texture_from_pixmap и визуализации, которые позволяют перемещать окна за пределы экрана и связывающиеся Х11 растров окна в качестве текстур в OpenGL. Прозвище, как это реализовано, называется AIGLX (Accelerated Indirect GLX), который, несмотря на то, что имя не зависит от косвенного контекста GLX. Косвенный в этом случае означает, что все происходит на сервере отображения.

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

Это отличается от Wayland, где композиторы do общаются с другими процессами напрямую, чтобы обмениваться информацией фреймбуфера. Лично мне нравится модель X11 лучше, но это только мое мнение.

+0

Я читал, что X вздувается, чрезмерно усложняется и, кроме того, отвечает за рендеринг приложений, а не за приложения, ответственные за рендеринг самих себя. Это не идеальный вариант, но с другой стороны он еще более полезен, чем соответствующие API-интерфейсы M $ windows и более поддерживается, чем Wayland.Мне очень нравится Wayland BTW, но на данный момент это не похоже, что он слишком полезен, если я правильно понял, он работает только с драйверами с открытым исходным кодом, чья производительность по-прежнему сильно не соответствует производительности проприетарных кадровых блоков, что к сожалению, не спешат поддерживать WL – 2014-09-28 21:57:13

+0

Я бы назвал X не очень раздутым. Это просто ужасно много для X-сервера. Кроме того, X-рендеринг приложений - это ИМХО очень интересная вещь. Потому что, когда каждое приложение выполняет рендеринг, каждое приложение должно иметь дело со всеми неприятными деталями, которые счастливо абстрагируются от сервера отображения. IMHO Wayland отлично подходит как серверный протокол между сервером отображения и графическими драйверами. Но ИМХО это отстой в качестве интерфейсного протокола. Я экспериментировал с ним (тем более в последние недели, из-за моих графических экспериментов с малой задержкой). – datenwolf

+0

@ user3735658: На моем рабочем столе, который я только отключил, я сохранил удивительно иллюстративный снимок экрана, почему приложения должны получать только абстрактный доступ к системе отображения и не отображать их сами: это скриншот MPD-клиента, написанный на GTK и в списке альбомов ему удается полностью испортить подпиксельное сглаживание и рендеринг шрифтов; похоже, он пытается применить некоторые масштабирующие преобразования, но каким-то образом они превращают уже обработанное изображение и сбивают его в неправильные субпиксели. Когда дело доходит до графических приложений, это похоже на маленьких детей. – datenwolf

Смежные вопросы