スタック型ウィンドウマネージャ

スタック型ウィンドウマネージャとは

スタック型ウィンドウマネージャは、ウィンドウが互いに重なり合うことを許容するウィンドウマネージャの一種で、フロート型ウィンドウマネージャとも呼ばれます。コンポジット型ウィンドウマネージャ以外の多くのウィンドウマネージャがこの方式を採用しています。ただし、同じスタック型でも、その実装方法は様々です。ウィンドウの重なりを許容しないウィンドウマネージャはタイル型と呼ばれます。

描画アルゴリズム

スタック型ウィンドウマネージャでは、ウィンドウの重なりを実現するために、主に以下の2つの描画アルゴリズムが用いられます。

1. 画家のアルゴリズム
このアルゴリズムでは、ウィンドウを奥から手前の順に描画していきます。これにより、手前のウィンドウが奥のウィンドウを隠す効果を自然に実現します。ただし、この方法は描画処理に時間がかかるという欠点があります。

2. クリッピング技法
この技法では、他のウィンドウに隠れている部分の描画をスキップすることで効率化を図ります。この方法では、ウィンドウを任意の順序で描画できますが、ウィンドウが明確な境界を持つ必要があります。

これらの処理は「スタッキング」とも呼ばれ、ウィンドウの重なり順序は「Zオーダー」と呼ばれます。

問題点

スタック型ウィンドウマネージャには、以下のような問題点が指摘されています。

描画処理の負荷: 画家のアルゴリズムでは、ウィンドウを奥から順に描画するため、処理に時間がかかることがあります。特に、ウィンドウの数が多い場合や、ウィンドウの内容が頻繁に更新される場合には、描画処理の負荷が大きくなります。
隠れた部分の再描画: ウィンドウが重なり合うと、隠れた部分の内容が消去されます。そのため、ウィンドウを手前に移動させる際や、ウィンドウの内容が変更された場合には、隠れていた部分を再描画する必要があります。再描画処理は各ウィンドウ自身が行う必要があり、アプリケーションが応答しなくなると再描画が正常に行われない場合があります。
GPUアクセラレーションの制限: 多くのスタック型ウィンドウマネージャでは、GPUによるハードウェアアクセラレーションを十分に活用できていないという問題があります。

問題への対処

これらの問題点を解決するために、以下のような技術が用いられています。

手前ウィンドウの特殊処理: 最前面のウィンドウを特別扱いし、他のウィンドウとは異なる方法でレンダリングすることで、ハードウェアアクセラレーションの恩恵を受けることができます。例えば、最前面のウィンドウの描画後に、その部分だけをハードウェアで加速されたテクスチャに置き換えるといった手法が用いられます。
テクスチャフィルタ: ウィンドウマネージャがアプリケーションに画面の更新されたイメージを供給することで、最前面のウィンドウを半透明にするなどの効果をテクスチャフィルタとして適用することができます。
ハードウェアオーバーレイとクロマキー: GPUの機能を利用して、ウィンドウの描画色を認識し、描画領域を検出することで、ハードウェアアクセラレーションによるビデオやアニメーションをウィンドウに追加できます。
フルスクリーンモード: ウィンドウ管理を一時的に停止し、アプリケーションがGPUに直接アクセスできるようにすることで、描画処理の負荷を軽減できます。

ハイブリッド型ウィンドウマネージャ

一部のウィンドウマネージャでは、手前のウィンドウを別の方法で処理し、その出力をGPUに送信することで、ラスターに合成します。これはコンポジット型ウィンドウマネージャに似た手法で、手前のウィンドウとその他の画面のラスターを合成します。この方法では、手前のウィンドウを透明にしたり、3Dで描画したりすることもできます。

ただし、この手法では、手前のウィンドウの領域外のオブジェクトとの相互作用が制限されることがあります。例えば、マウスイベントが意図しないウィンドウに送信されることがあります。

X Window System

X Window Systemは、ウィンドウの重なりを許容するように設計されており、スタック型としてもタイル型としても利用できます。元々はウィンドウの合成機能はサポートされていませんでしたが、後に拡張機能として追加されました。Xにおけるウィンドウマネージャは、アプリケーションが表示する最上位のウィンドウを管理するものであり、各ウィンドウ内部の管理はアプリケーションに任されています。そのため、タイル型ウィンドウマネージャを使用している場合でも、最上位ウィンドウ内部での重なりは可能です。

Xにおけるスタック型ウィンドウマネージャは、他のスタック型ウィンドウマネージャと同様の課題を抱えていますが、ウィンドウマネージャの選択肢が豊富で、互換性が高いという利点があります。X Composite拡張により、コンポジット型ウィンドウマネージャの実装も可能になり、様々な方法でウィンドウの親子関係情報を使用できます。これにより、ほとんどのプログラムがシームレスに動作することを可能にしています。

X Window System でスタック型機能を提供するウィンドウマネージャの例

Metacity
Compiz
KWin

Microsoft Windows

Windows 1.0ではタイル型ウィンドウマネージャが採用されていましたが、Windows 2.0でスタック型ウィンドウマネージャに置き換えられました。しかし、タイル型ウィンドウ管理は限定的なものに留まりました。Windows XPまではスタック型ウィンドウマネージャが採用されていたため、ハードウェアアクセラレーションを使用したコンテンツの表示に制限がありました。Windows Vistaからはコンポジット型ウィンドウマネージャがデフォルトとなり、それまでのスタック型ウィンドウマネージャはWindows 7で選択式で残されましたが、Windows 8で廃止されました。

歴史

1970年代: Xerox Altoが世界初の商用GUIを搭載し、スタック型ウィンドウマネージャを採用しました。
1980年代初期: Xerox Starでは、ほとんどのウィンドウをタイル型で表示し、ダイアログボックスのみオーバーラップを許可していました。
Classic Mac OS: スタック型ウィンドウを早くから採用し、商業的に成功しました。
GEM: Microsoft Windowsより前にスタック型ウィンドウを採用しましたが、Appleとの訴訟により機能を削除させられました。
* AmigaOS: 当時としては非常に高度なスタック型ウィンドウマネージャを搭載していました。

もう一度検索