Стековый менеджер окон

Стековый менеджер окон (также называемый диспетчером плавающих окон) - это менеджер окон, который рисует все окна в определенном порядке, позволяя им перекрываться, используя технику, называемую алгоритмом художника. Все оконные менеджеры, которые допускают перекрытие окон, но не композитные менеджеры окон, считаются составными оконными менеджерами, хотя возможно, что не все используют точно одинаковые методы. Другие оконные менеджеры, которые не считаются стековыми менеджерами окон, называются фреймовыми оконными менеджерами^[1], которые не допускают перекрытия окон.

Стековые менеджеры окон позволяют окнам перекрываться, рисуя их по одному за раз. Наложение или перекрашивание (в соответствии с алгоритмом художника) относится к визуализации каждого окна в виде изображения, нарисованного непосредственно над рабочим столом и поверх любых других окон, которые уже могли быть нарисованы, эффективно стирая покрываемые области. Процесс обычно начинается с рабочего стола и продолжается рисованием каждого окна и любых дочерних окон сзади вперед, пока, наконец, не будет нарисовано окно переднего плана.^[2]

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

Ограничения

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

Хорошо известным недостатком наложения является то, что когда окна закрашены друг на друга, они фактически стирают предыдущее содержимое любой части экрана, которую они покрывают. Эти окна должны быть перерисованы, когда они выводятся на передний план или когда видны их части. Когда окно изменено или когда изменилась его позиция на экране, диспетчер окон обнаружит это и может перекомпоновать все окна, требуя перерисовки каждого окна, и передать его новый внешний вид диспетчеру окон перед его прорисовкой. Когда приложение перестает отвечать на запросы, оно может быть не в состоянии перерисовать себя, что иногда приводит к тому, что область внутри рамки окна сохраняет изображения других окон, когда она выводится на передний план. Эта проблема обычно наблюдается в Windows XP и более ранних версиях, а также в некоторых менеджерах окон X Window System.

Другое серьезное ограничение, которое затрагивает почти все cтековые менеджеры окон, состоит в том, что они часто сильно ограничены в степени, в которой интерфейс может быть ускорен графическим процессором (GPU), и с этим очень мало что можно сделать.

Как избежать ограничений

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

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

Однако, если оконный менеджер также может предоставить приложению обновленное изображение того, как выглядел экран до того, как было нарисовано окно переднего плана, но после того, как все другие окна уже нарисованы, открываются дополнительные возможности. Это позволило бы одному окну на переднем плане выглядеть полупрозрачным, если использовать изображение в качестве фильтра текстуры в конечном выводе. Это было возможно в Windows XP с ПО в комплекте со многими NVidia GeForce видеокартами, а также из третьих источников, с использованием аппаратного наложения текстур.^[3]

Еще один метод уменьшения ограничений наложений — использование аппаратного наложения и хромакея . Поскольку графический процессор может рисовать на исходящем экране, рисуется окно, содержащее известный цвет, который позволяет видеоаппаратуре определять, какие части окна отображаются и на которые следует рисовать. Этот способ позволяет добавлять в окна 3D и 2D ускоренное видео и анимацию.

Полноэкранное видео также может рассматриваться как способ избежать ограничений, накладываемых наложением. Полноэкранный режим временно приостанавливает необходимость какого-либо управления окнами, позволяя приложениям иметь полный доступ к видеокарте. Ускоренные 3D-игры в Windows XP и более ранних версиях полностью основывались на этом методе, поскольку в эти игры было бы невозможно играть в оконном режиме. Однако технически этот метод не имеет ничего общего с оконным менеджером и является просто средством его замены.

Гибридные оконные менеджеры

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

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

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

X Window System

Многие менеджеры окон в X Window System предоставляют функциональность окон стека:

Microsoft Windows

Microsoft Windows 1.0 отображала окна, используя фреймовый менеджер окон. В Windows 2.0 он был заменен стековый менеджером окон, который позволял перекрывать окна. Microsoft поддерживала стековый менеджер окон до Windows XP, что представляло серьезные ограничения для его способности отображать аппаратно ускоренный контент в обычных окнах. Хотя технически возможно было создать некоторые визуальные эффекты с помощью стороннего программного обеспечения.^[3] Начиная с Windows Vista, новый композитный менеджер окон используется по умолчанию на совместимых системах.^[4]

История

• 1970-е годы: Xerox Alto, который содержал первый работающий коммерческий графический интерфейс, использовался стековый менеджер окон.^[5]
• Начало 1980-х годов: Xerox Star, преемник Alto, использовал фреймовый оконный менеджер для большинства основных окон приложений и использовал перекрытие только для диалоговых окон, устраняя необходимость в полной укладке.^[6]
• Классическая Mac OS была одним из первых коммерчески успешных примеров графического интерфейса пользователя, в котором использовались стекируемые окна.
• GEM 1.1 предшествовал Microsoft Windows и использовал стекирование, позволяя перекрывать все окна.^[7] В результате судебного иска Apple, GEM был вынужден убрать возможности стекирования.^[8]
• Amiga OS содержит ранний пример очень продвинутого оконного менеджера стеков.

См. также

• Менеджер окон
• Фреймовый оконный менеджер
• Композитный менеджер окон

Примечания

Ссылки

• Галерея графического интерфейса пользователя

Эта страница в последний раз была отредактирована 2 мая 2023 в 12:01.