ウィンドウ システム

フリー百科事典ウィキペディアより
ナビゲーションにジャンプ 検索にジャンプ
ウィンドウの典型的な要素ウィンドウの装飾は、ウィンドウ マネージャまたはクライアントによって描画されます。コンテンツの描画はクライアントのタスクです。

コンピューティングでは、ウィンドウ システム(またはウィンドウ システム) は、表示画面の異なる部分を個別に管理するソフトウェアです[1]ユーザー インターフェイスのWIMP (ウィンドウアイコンメニューポインター) パラダイムを実装するグラフィカル ユーザー インターフェイス( GUI)の一種です

現在実行中の各アプリケーションには、ユーザーに GUI を表示するために、通常はサイズ変更可能で通常は長方形の画面が割り当てられます。これらのウィンドウは、オーバーラップが許可されていないタイリング インターフェイスとは対照的に、互いにオーバーラップする場合があります。通常、窓飾りは各窓の周りに描かれます。ウィンドウの装飾と、ウィンドウ内で使用可能なウィジェット(スライダー、ボタンなど、ユーザーが直接操作するためのグラフィカル要素) の両方のプログラミングは、ウィジェット ツールキットを使用することで容易になり、簡素化されます。

技術的な詳細

ウィンドウ システムの主要なコンポーネントは、通常はディスプレイ サーバーと呼ばれますが、ウィンドウ サーバーやコンポジターなどの別の呼称も使用されています。GUI を実行してウィンドウに表示するアプリケーションは、ディスプレイ サーバーのクライアントです。ディスプレイ サーバーとそのクライアントは、通常ディスプレイ サーバー プロトコルと呼ばれる通信プロトコルを介して相互に通信します。ディスプレイ サーバーは、クライアントとユーザーの間の仲介者です。カーネルからのすべての入力を受け取ります。カーネルは、キーボードポインティング デバイスタッチスクリーンなど、接続されているすべての入力デバイスから受け取ります。正しいクライアントに送信します。ディスプレイ サーバーは、コンピュータ モニタへのクライアントの出力も担当します通常、サウンドの出力はディスプレイ サーバーによって管理されませんが、サウンド ボリュームは通常 GUI アプレットによって処理され、どのアプリケーションを優先するかを決定するのはディスプレイ サーバーです。ウィンドウ システムにより、コンピュータ ユーザーは同時に複数のプログラムを操作できます。各プログラムは、通常、画面の長方形の領域である独自のウィンドウに GUI を表示します。[引用が必要]

プログラマーの観点から見ると、ウィンドウ システムはグラフィカル プリミティブを実装します例:フォントのレンダリングまたは画面上での線の描画。これは、ウィンドウ マネージャーなどのグラフィカル インターフェイスの上位レベルの要素で使用するグラフィック ハードウェアの抽象化を提供します。[引用が必要]

ディスプレイ サーバー プロトコルは、ネットワーク対応またはネットワーク トランスペアレントにすることができ、シン クライアントの実装を容易にします[引用が必要]

表示サーバー

GUIの基本コンポーネント:ディスプレイ サーバーは、ウィンドウ システムを実装します。単純なウィンドウ マネージャーはウィンドウの装飾を描画するだけですが、合成ウィンドウ マネージャーはそれ以上のことを行います。

ディスプレイ サーバーまたはウィンドウ サーバーは、そのクライアントの入出力をオペレーティング システムの残りの部分、ハードウェア、および相互に調整することを主なタスクとするプログラムですディスプレイ サーバーは、ディスプレイ サーバー プロトコル (通信プロトコル) を介してクライアントと通信します。

ディスプレイ サーバーは、グラフィカル ユーザー インターフェイス、特にウィンドウ システムの重要なコンポーネントです。

サーバー通信プロトコルを表示する

X11

X.Org サーバーは、X11 プロトコルを介してAmarokなどのクライアントと通信します
X ウィンドウ システムのロゴ

ディスプレイ サーバーの 1 つの例はX.Org サーバーで、カーネル (通常はLinuxBSDなどのUnix ライクなカーネル) 上で実行されます。ユーザー入力データ (Linux のevdevなど) を受け取り、クライアントの 1 つに渡します。ディスプレイ サーバーは、クライアントからもデータを受信します。データを処理し、合成を行い、Linux ではデータを 3 つのカーネル コンポーネント ( DRMgemまたはKMS driver ) のいずれかに渡します。コンポーネントはデータをフレームバッファに書き込み、フレームバッファの内容は接続された画面に送信されて表示されます。X はGLXに依存しています。

ディスプレイ サーバーの概念の実装の 1 つはX Window Systemで、特に実際に使用されているバージョンのX.Org サーバーXlibおよびXCBクライアント ライブラリです。X.Org サーバーはディスプレイ サーバーですが、現在の実装では、合成を行うために 2 つ目のプログラムである合成ウィンドウ マネージャーに依存しています。例はMutterKWinです。

X11 ディスプレイ サーバー プロトコルを実装するディスプレイ サーバーの注目すべき例はX.Org ServerXFree86XQuartz、およびCygwin/Xであり、X11 ディスプレイ サーバー プロトコルを実装するクライアント ライブラリはXlibおよびXCBです。

ウェイランド

Wayland ディスプレイ サーバー プロトコル
ウェイランドのロゴ

Wayland ディスプレイ サーバー プロトコルを実装するディスプレイ サーバーは、 Wayland コンポジター と呼ばれます他のディスプレイ サーバーと同様に、Wayland コンポジターはクライアントの入力と出力を処理し、X11 とは対照的に合成も行います。例としては、WestonMutterKWin、またはEnlightenmentがあります。

Wayland コンポジターは、 Wayland ディスプレイ サーバー プロトコルを介して Wayland クライアントと通信しますこのプロトコルは、クライアントがEGL レンダリング APIを使用してフレームバッファーにデータを直接書き込むことができることを定義しますディスプレイサーバーは、どのウィンドウが一番上にあり、ユーザーに表示されるかを決定し、入力デバイスに関するデータをevdevからそのクライアントに渡す責任があります。

Wayland は、 Fedoraなどの一部の Linux デスクトップ ディストリビューションである程度使用されていますまた、モバイル コンピューティングにも適しており、スマートフォンやタブレット向けのプロジェクトTizenSailfish OSAsteroidOSなどで採用されています。

Wayland の実装は、MIT ライセンスlibwayland-clientおよび libwayland-server ライブラリの下で利用できます。

Wayland のサポートをChrome OSに追加する取り組みが進行中です。[2]

ミール

Mir ディスプレイ サーバーには、X11 や Wayland で使用されているものとは異なる独自の Mir ディスプレイ サーバー プロトコルが付属していますMir はさらに X11 プロトコルをサポートします。これはCanonicalによって開発されたもので、 Ubuntuに最適なディスプレイ サーバーになることを目的としていました2017 年の時点で、Ubuntu のデスクトップ エディションの Wayland ディスプレイ サーバーに置き換えられました。

Mir ディスプレイ サーバー、libmir-server、および libmir-client ライブラリの実装がGPLv3で利用可能です。

SurfaceFlinger

Googleは、SurfaceFlinger [3]と呼ばれるAndroid (主にモバイル デバイス用の別の Linux カーネル ベースのオペレーティング システム) 用 のディスプレイ サーバーを開発しました。

Android のすべてが「表面」にレンダリングされます。「サーフェス」はアプリケーションによって生成され、SurfaceFlinger によって管理されるキューに配置されます。[4] [5]

もう 1 つの Android 固有のソリューションは「Gralloc」です。Gralloc はデバイス メモリを処理します。つまり、割り当て、調停を行い、Android/Linux フェンス ファイル記述子を介して同期を処理します。Gralloc は、Mesa のGeneric Buffer Management (GBM) や Nvidia の EGLStreams などの他のソリューションと競合します。Grallocハードウェア アブストラクション レイヤー (HAL)を使用して、「サーフェス」の基礎となるバッファーを割り当てます。

Android での合成では、Surface が SurfaceFlinger に送信され、OpenGL ES を使用して合成が行われます。

Hardware Composer HAL (HWC) は Android 3.0 で導入され、長年にわたって着実に進化してきました。その主な目的は、使用可能なハードウェアでバッファを合成する最も効率的な方法を決定することです。HAL として、その実装はデバイス固有であり、通常はディスプレイ ハードウェア OEM によって行われます。

Quartz Compositor

Apple のmacOSファミリーのオペレーティング システムの場合、Quartz Compositorは、ウィンドウ システムのディスプレイ サーバーとウィンドウ マネージャーのタスクを実行します。

デスクトップ ウィンドウ マネージャー

Microsoft Windowsの場合Windows Vista以降では、デスクトップ ウィンドウ マネージャーを使用すると、ハードウェア アクセラレーションを使用してグラフィカル ユーザー インターフェイスをレンダリングできます。これはもともと、新しい「Windows Aero」ユーザー エクスペリエンスの一部を有効にするために作成されました。これにより、透明度、3D ウィンドウの切り替えなどの効果が可能になりました。Windows Server 2008 にも含まれていますが、「デスクトップ エクスペリエンス」機能と互換性のあるグラフィックス ドライバーをインストールする必要があります。Windows 8 以降では、DWM を無効にすることはできず、適切なグラフィックス カードがインストールされていない場合 はソフトウェアでレンダリングされます。

ウィンドウ システムのリスト

Unix ライクなオペレーティング システムの場合

Windows NT ファミリオペレーティング システムの場合

Webウィンドウ システム

その他

Microsoft Windows ( XP9x以前)、従来の Mac OS (バージョン9以前)、およびPalm OSなどの一部のシステムには、OS に統合されたウィンドウ システムが含まれています。[引用が必要]

も参照

参考文献

  1. ^ ケント、アレン。ウィリアムズ、ジェームズ G. (1996-10-11)。マイクロコンピュータ百科事典: 第 19 巻 - ビジュアル ディスプレイ品質への真実のメンテナンス システムCRCプレス。p。227.ISBN _ 9780824727178. 2017年6月8日閲覧
  2. ^ 「オゾンの概要」. 2017 年 8月20 日閲覧
  3. ^ 「Android システム アーキテクチャ」(PDF) . 2016-04-08に元の(PDF)からアーカイブされました。
  4. ^ "Android 開発者: Surface" .
  5. ^ 「Android デベロッパー: SurfaceFlinger と Hardware Composer」 .
  6. ^ 「HP Windows/9000 ユーザー マニュアル」(PDF) . ヒューレット・パッカード。1988 年 4 月2021年10月26日閲覧
  7. ^ マイヤーズ、ブラッド (1984 年 12 月)。「Sapphire のユーザー インターフェイス」(PDF) . IEEE コンピュータ グラフィックスとアプリケーション. 4 (12): 13–23. ドイ: 10.1109/MCG.1984.6429376 .