「スタック型ウィンドウマネージャ」の版間の差分
画家のアルゴリズムに加えてクリッピングに言及した。また、X がスタック型を許す設計であることを記載した。 |
m Bot作業依頼: Apple関連記事の改名に伴うリンク修正依頼 (Apple|Apple) - log |
||
| 86行目: | 86行目: | ||
* [[1980年代]]初期 : Altoの量産型である[[Xerox Star]]はほとんどのアプリケーションウィンドウについてはタイル型を使い、[[ダイアログボックス]]だけにオーバーラップを許していた。これによって完全なスタック型の必要性を排除していた<ref>[http://toastytech.com/guis/star.html The Xerox Star]</ref>。 |
* [[1980年代]]初期 : Altoの量産型である[[Xerox Star]]はほとんどのアプリケーションウィンドウについてはタイル型を使い、[[ダイアログボックス]]だけにオーバーラップを許していた。これによって完全なスタック型の必要性を排除していた<ref>[http://toastytech.com/guis/star.html The Xerox Star]</ref>。 |
||
* [[Classic Mac OS]]は早くからスタック型ウィンドウを使った[[グラフィカルユーザインタフェース|GUI]]により商用で成功した例である。 |
* [[Classic Mac OS]]は早くからスタック型ウィンドウを使った[[グラフィカルユーザインタフェース|GUI]]により商用で成功した例である。 |
||
* [[Microsoft Windows]]より以前に登場した[[Graphical Environment Manager|GEM]] 1.1はスタック型であり、ウィンドウのオーバーラップが完全に可能だった<ref>[http://toastytech.com/guis/gem11.html GEM 1.1]</ref>。[[ |
* [[Microsoft Windows]]より以前に登場した[[Graphical Environment Manager|GEM]] 1.1はスタック型であり、ウィンドウのオーバーラップが完全に可能だった<ref>[http://toastytech.com/guis/gem11.html GEM 1.1]</ref>。[[Apple]]との訴訟の結果、GEMはスタック型の機能を削除させられた<ref>[http://toastytech.com/guis/gem20.html GEM 2.0]</ref>。 |
||
* [[AmigaOS]]は当時としては極めて先進的なスタック型ウィンドウマネージャを搭載していた。 |
* [[AmigaOS]]は当時としては極めて先進的なスタック型ウィンドウマネージャを搭載していた。 |
||
2021年5月20日 (木) 12:28時点における最新版
スタック型ウィンドウマネージャ（スタックがたウィンドウマネージャ、英: stacking window manager）は、ウィンドウマネージャの分類のひとつであり、ウィンドウのオーバーラップを許すものである。フロート型ウィンドウマネージャ（英: floating window manager）とも呼ばれる。コンポジット型ウィンドウマネージャ以外でウィンドウのオーバーラップを許すウィンドウマネージャは、全てスタック型ウィンドウマネージャと見なすことができる。しかし、それらが全てまったく同じ手法を使っているとは限らない。スタック型でもコンポジット型でもないウィンドウマネージャとはウィンドウのオーバーラップを許さないもので、それらをタイル型ウィンドウマネージャと呼ぶ[1]。
アルゴリズム
[編集]スタック型ウィンドウマネージャは、画家のアルゴリズムを使った再描画では、一度に全ウィンドウを描画することでオーバーラップを可能にしている。ウィンドウを後ろにあるものから順にデスクトップ上に直接描画していき、オーバーラップしている部分があれば、上にあるウィンドウの描画によって下のウィンドウの隠される部分が効果的に消去される[2]。
クリッピング技法（英語版）を使った再描画では、他のウィンドウに覆われている箇所の描画をスキップすることにより同様の効果を実現する。この技法では各ウィンドウへの描画を任意の順序で行うことが出来る。一方、そのためにはウィンドウは明確な境界を持つ必要がある。
これらの処理をスタッキング（英: stacking）とも呼ぶ。なお、ウィンドウの積み重ねの順序をZオーダーと呼ぶ。
問題
[編集]画家のアルゴリズムは比較的時間のかかる処理で、ウィンドウを1つずつ、下（画面の奥）から上（画面の手前）へと順番に描画しなければならない。多くの場合、バックグラウンドのウィンドウ群を常に再描画するわけではない。全ウィンドウの再描画が必要なときそれを検出できるものもあり、例えばアプリケーションが自分の出力が変化したときにスタッキングを要求する。再スタッキングは一般にウィンドウマネージャへの関数呼び出しを通して行われ、選択的なウィンドウ群の再描画が可能である。例えば、バックグラウンドのウィンドウが一番手前に来るとき、そのウィンドウだけを再描画すればよい。
よく知られているスタック型の短所は、ウィンドウが重なり合うとき、重なりによって隠れる部分の内容が消去される点である。その部分は問題のウィンドウを手前に持ってくるときに再描画しなければならず、またそのウィンドウの見えている部分が変化したときも再描画が必要である。あるウィンドウの中身や位置が変化したとき、ウィンドウマネージャがそれを検出し、必要があれば全ウィンドウの再スタッキングをする。ウィンドウの中身の再描画は各ウィンドウ自身が行う必要があり、描画する前にその新しい外観をウィンドウマネージャに渡す必要がある。アプリケーションが応答しなくなると、対応するウィンドウを再描画できなくなることがあり、そうなるとそのウィンドウを手前に持ってくる前に表示されていた別のウィンドウの中身がそのまま残ることがある。Windows XP以前にはこの現象がよく見られたし、X Window Systemでも（コンポジット型ウィンドウマネージャでない限り）同様である。
もう1つのほとんどのスタック型ウィンドウマネージャに共通の問題は、Graphics Processing Unit (GPU) によるアクセラレーションをほとんど利用できない点である。
問題への対処
[編集]いくつかの技術革新により、スタック型の問題の一部を低減させたり除去したりできるようになってきた。ハードウェア・アクセラレーションが利用できないという問題については、一番手前にある1つのウィンドウだけを特殊ケースとして扱い、他のウィンドウとは異なるレンダリングを行うという手法がある。
手前のウィンドウは最後に所定の位置に描画され、他のウィンドウによって隠されないので、これはウィンドウマネージャの再設計を必要とするとは限らない。したがって、手前のウィンドウが描画された後、その部分だけをスクリーン上で容易に分離可能である。すると、手前のウィンドウの位置がわかっているので、スクリーンのラスターがグラフィックス・ハードウェアに達したとき、手前のウィンドウが占めている領域を容易にアクセラレートされたテクスチャに置き換えることができる。
しかし、一番手前のウィンドウを描く前で他の全ウィンドウを描いた後、画面がどう見えるかの更新されたイメージもウィンドウマネージャがアプリケーションに供給できるなら、より多くの可能性が開ける。これにより最終的な出力において、前のイメージをテクスチャ・フィルタとして使って手前の1つのウィンドウを半透明することを可能にする。Windows XPではNVIDIA GeForceのビデオカードなどに同梱されているソフトウェアやサードパーティーのソフトウェアを使い、ハードウェアのテクスチャ・オーバーレイ機能を使ったこのような視覚効果を可能にしていた[3]。
スタック型の問題を改善するもう1つの方法は、ハードウェア・オーバーレイとクロマキーを使うものである。GPUは出力すべき画面に描画でき、ウィンドウの描画される色は判っているので、GPUがウィンドウのどの部分が見えているか、どう描画すべきか検出できる。この方法を使えば、3Dおよび2Dのアクセラレートされたビデオおよびアニメーションをウィンドウに追加できる。
スタック型の問題を防ぐ方法として、フルスクリーンでのビデオ表示も考えられる。フルスクリーンモードでは一時的にウィンドウ管理が不要となり、アプリケーションがGPUへの完全なアクセスを行えるようにする。Windows XP やそれ以前のOS上でアクセラレートされた3Dゲームを実行する場合はこの方法に完全に依存しており、そのようなゲームはウィンドウモードではプレイできなかった。しかし技術的には、この方法ではウィンドウマネージャに何ら変更を加える必要がなく、単にウィンドウマネージャに取って代わるだけである。
ハイブリッド型ウィンドウマネージャ
[編集]一部のウィンドウマネージャは手前のウィンドウを全く異なった方式で扱うことができ、レンダリングを間接的に行い、その出力をGPUに送ることで出力中のラスターに追加する。一部のスタック型ウィンドウマネージャはこの技法が可能だが、これは技術的には合成（コンポジット）であり、コンポジット型ウィンドウマネージャで2つのウィンドウを合成するように手前のウィンドウとそれ以外の画面のラスターを合成していると言える。
先述した通り、手前のウィンドウがまだ描画されていないスタッキング完了前の段階にアクセスすることになる。後でそれを描画してGPUにセットするとしても、単純にそれをハードウェアレベルで若干古いバージョンを使って完全に上書きすることもでき、本来のウィンドウの位置とは異なる位置に合成することも可能である。これによって手前のウィンドウを透明にしたり、三次元で描いたりすることも可能である。
しかし、手前のウィンドウの本来の領域の外のオブジェクトと相互作用することは不可能ということもある。例えば、ユーザーがマウスをクリックしたとき、それがどの領域でなされたかによってマウスイベントの行き先が決まるので、手前のウィンドウをクリックしたつもりがその下のウィンドウにイベントが送信されるということがありうる。
X Window System
[編集]X はウィンドウ同士の重なりを許すように設計された。これは、スタックを強制するものではなく、むしろスタック型としてもタイル型としても利用できるようにするためである。何故ならウィンドウ同士の重なりを許可しない設計ではスタック型のウィンドウ管理は不可能だからである。一方で、当初はウィンドウの合成はサポートしておらず、のちに拡張機能として追加された。
なお X におけるウィンドウマネージャは、アプリケーションが表示する最上位のウィンドウを管理するものであり、各最上位ウィンドウの内部の管理は各アプリケーションに任されている。従って、タイル型のウィンドウマネージャを利用している場合も、最上位ウィンドウ内部では描画領域の重なりは可能である。
X におけるスタック型ウィンドウマネージャは他の任意のスタック型ウィンドウマネージャと同じ限界があるが、ただ1つ利点がある。それは、ウィンドウマネージャの選択肢が広く、相互に交換可能という点である。X Composite拡張を追加すると、コンポジット型ウィンドウマネージャの実装も含めて様々な方法でウィンドウの親子関係情報を使う可能性があり、タイル型ウィンドウマネージャではそれを無視するが、どちらにしても完全なアプリケーション・サポートが維持され、1つのウィンドウマネージャに対応して書かれた事実上全てのプログラムが互いにシームレスに動作することを可能にしている。以下にスタック型の機能を提供するウィンドウマネージャを挙げる。
Microsoft Windows
[編集]Windows 1.0はタイル型ウィンドウマネージャを使って表示していた。Windows 2.0でタイル型ウィンドウマネージャはスタック型ウィンドウマネージャに置き換えられ、ウィンドウのオーバーラップが可能となった。一方で、タイル型のウィンドウ管理は今日に至るまで限定的なものに留まることとなった。マイクロソフトはWindows XPまでスタック型ウィンドウマネージャを採用していたため、ハードウェアによるアクセラレーションが行われたコンテンツを通常のウィンドウ内へ表示を行う能力に重大な制限が課せられていたが、サードパーティーのソフトウェアを使ってなんらかの視覚効果を生み出すことは技術的に可能であった[3] 。Windows Vistaからは新しいコンポジット型ウィンドウマネージャがシステムのデフォルトウィンドウマネージャとなった[4]。それまでのスタック型ウィンドウマネージャはMicrosoft Windows 7まで選択式で残され、Microsoft Windows 8で廃止された。
歴史
[編集]- 1970年代 : 世界初の商用レベルのGUIを搭載したXerox Altoでは、スタック型ウィンドウマネージャを使っていた[5]。
- 1980年代初期 : Altoの量産型であるXerox Starはほとんどのアプリケーションウィンドウについてはタイル型を使い、ダイアログボックスだけにオーバーラップを許していた。これによって完全なスタック型の必要性を排除していた[6]。
- Classic Mac OSは早くからスタック型ウィンドウを使ったGUIにより商用で成功した例である。
- Microsoft Windowsより以前に登場したGEM 1.1はスタック型であり、ウィンドウのオーバーラップが完全に可能だった[7]。Appleとの訴訟の結果、GEMはスタック型の機能を削除させられた[8]。
- AmigaOSは当時としては極めて先進的なスタック型ウィンドウマネージャを搭載していた。