test

Sun フレームバッファー使用の手引き

第 5 章 Creator ウィンドウシステム

この章では、Creator とCreator 3D グラフィックスアクセラレータ上での、Solaris の X11 ウィンドウシステムの動作について説明します。

Creator アクセラレータは、GX、SX、ZX、S24 などのディスプレイアダプタの機能を集約した、高機能のアクセラレータです。Creator アクセラレータは、ZX グラフィックスアクセラレータと同様に、以下のようなフレームバッファーの拡張機能を備えています。

Creator アクセラレータは、SX アクセラレータと同様に、X チャネルアーキテクチャーのディスプレイアダプタです。「Creator の画像表示形式」を参照してください。

Creator アクセラレータは、GX アクセラレータと同様に、高速化された X11 の描画操作とハードウェアカーソルをサポートします。「カーソルの使用方法」を参照してください。

Creator アクセラレータは、S24 アクセラレータと同様に、ガンマ補正された画像と、非補正の画像の両方を備えています。「Creator の画像表示形式」を参照してください。

Creator アクセラレータは、GX、SX および ZX グラフィックスアクセラレータと同様に、複数のモニターの表示モードをサポートします。「デバイスの設定」を参照してください。

Creator アクセラレータは、SB (Creator) と DBZ (Creator 3D) のどちらにも設定することができます。SB は "Single Buffer"、DBZ は "Double Buffer plus Z" を意味します。Z値は、ピクセルごとの深さを表します。それぞれの設定では、ボード上のビデオメモリーの大きさが異なります。Creator 3D アクセラレータでは、ハードウェアのダブルバッファリングと 3 次元描画を実行するためのメモリーが付加されています。

Creator の画像表示形式

Creator アクセラレータの出荷時のデフォルト表示形式は、8 ビット疑似カラーです。他のデフォルトを設定するには、Xsun(1) の defdepth および defclass オプション、または ffbconfig(1m) の -defoverlay および -deflinear オプションを使用してください。

注 -

Creator アクセラレータの別名は FFB (Fast Frame Buffer) です。このコード名は、Creator ソフトウェアのパッケージ名、ロード可能なデバイスのパイプラインモジュール名、設定プログラム名、デバイスのマニュアルページ名などに使用されています。

OpenWindows を起動する際に、通常の OpenWindows のコマンド行オプションを使用して、デフォルトの表示形式を変更することができます。使用可能な表示形式は、すべてデフォルトとして選択することができます。openwin defdepth 24 オプション (Xsun(1) を参照) を使用して 24 ビットトゥルーカラーをデフォルトに設定した場合には、カラーマップのフラッシュ現象が減少します。

画像表示形式のリスト

Creator アクセラレータによって、X11 の画面の画像表示形式リスト上の 11 種類の表示形式が使用可能となります。画像表示形式は、XGetVisualInfo(3) または XMatchVisualInfo(3) を使用して照会することができます。また、表示形式のリニア性 (線形性) については、XSolarisGetVisualGamma(3) によって照会することができます。

以下に使用可能な 11 種類の表示形式を示します。

注 -

上記の画像表示形式において、特にリニア画像に設定されていない場合は、ガンマ補正されていない非リニア画像となります。また 8 ビットの画像は、特にオーバーレイに指定されていない場合には、Creator アクセラレータのアンダーレイのプレーングループとなります。24 ビットの画像は、常にアンダーレイとなります。

表 6-1 に、Creator アクセラレータの画像の、フレームバッファー内のピクセル記憶装置（プレーングループ）に対する関連を示します。X、B、G、R は、ピクセルのデータが格納される 4 種類の 8 ビットチャネルを示します。図では、拡張オーバーレイが無効になっている Creator シリーズ 1、2、3 用のピクセル領域を示しています。

B、G、R チャネルは、8 ビットのピクセルデータ（赤のチャネルだけ）と、24 ビットのピクセルデータ（3 種類のチャネルを使用）のどちらも格納することができます。R チャネルは、7 種類の異なる画像 （8R 画像）をウィンドウに格納します。BGR チャネルは、ウィンドウに 3 種類の異なる画像（24 ビットの画像）を格納します。X チャネルは、8X の疑似カラーの 1 種類だけを格納します。

図 5-1 Creator アクセラレータの 11 種類の画像表示形式

Graphic

アンダーレイ画像のカラーマップのサイズは 256 です。Creator シリーズ 1 および 2 では オーバーレイ画像のカラーマップのサイズは 256 - maxwids です。 Creator シリーズ 3 は、256 色フルカラーオーバーレイを使用するか、256 - maxwids 色のシリーズ 1 または 2 との互換モードで動作するように設定できます。

オーバーレイとアンダーレイの構造

アンダーレイの 8 ビット疑似カラー画像は、ピクセルがフレームバッファーの赤のチャネルに格納されるため、8R 画像と呼ばれます。また、オーバーレイの 8 ビットの疑似カラーは X チャネルに格納されるため、8X 画像と呼ばれます。

オーバーレイ画像のウィンドウ上のピクセルは、アンダーレイ画像のウィンドウ上のピクセルに影響しません。ただし、アンダーレイ画像のウィンドウ上のピクセルは、オーバーレイ画像のウィンドウ上のピクセルに影響します。これは、アンダーレイウィンドウが BGR チャネル (あるいは R チャネルだけ) に依存するカラーデータであるのに、X チャネル上に WID 情報も持っているためです。x11 expose event (障害) の発生の原因となります。

オーバーレイウィンドウがアンダーレイウィンドウに遮断されている場合、アンダーレイデータの WID 部分によってオーバーレイウィンドウのカラーデータが破壊されてしまいます。アンダーレイウィンドウが再び取り除かれると、x11 expose event がオーバーレイウィンドウの破壊された部分に送り出されます。これは、互いに干渉しないアンダーレイとオーバーレイを備えた ZX アクセラレータとは異なります。Creator アクセラレータの 8 ビットのアンダーレイのウィンドウ上のピクセルは、24 ビットのアンダーレイのウィンドウ上のピクセルに影響します。

Creator アクセラレータは、X チャネルアーキテクチャーに従います。このアーキテクチャーでは、8X プレーングループ表示に使用されていない色のピクセル値とコードを、アンダーレイ画像のピクセル表示を操作するウィンドウ ID として使用します。

Creator 3D シリーズ 3 には、ZX アクセラレータと同様の非干渉型のオーバーレイとアンダーレイを持つ拡張オーバーレイモードが備えられています。このモードが有効になると、WID プレーングループは X またはオーバーレイチャネルを共有しなくなるため、x11 expose event (障害) は発生しなくなります。

maxwids とは、オーバーレイのピクセル値をハードウェアウィンドウ ID として、どの程度使用するかを特定する ffbconfig(1M) 設定オプションです。詳細は、「ハードウェアのウィンドウ ID」を参照してください。maxwids の最小値は 1、デフォルト値は 32 です。オーバーレイ画像は、通常のカラーマップのエントリ数が 256 より少ないため、部分画像となります。この画像のカラーマップに、クライアントが指定されたカラーマップエントリの数以上のピクセル値で描画すると、エラーは発生しませんが、表示された色の定義はされません。

SX アクセラレータとの比較

Creator アクセラレータの画像表示アーキテクチャーは、SX アクセラレータのディスプレイアダプタである CG14 と類似しています。CG14 もまた、8 ビットまたは 24 ビットのアンダーレイ画像と単一 8 ビット疑似カラーのオーバーレイ画像を備えた、X チャネルアーキテクチャーのディスプレイアダプタです。Creator アクセラレータの画像表示アーキテクチャーと CG14 には、以下の 2 つの大きな違いがあります。

ガンマ補正

Creator アクセラレータには、ガンマ補正ありの画像表示形式と、ガンマ補正なしの画像表示形式があります。ガンマ補正された画像は、リニア画像と呼ばれます。以下にリニア画像の種類を示します。

リニア画像と非リニア画像は、どちらも X11 画面の画像リスト上に存し、XGetVisualInfo によって照会することができます。リニア性は、X11 コアプロトコルで認識される画像上の特性ではないため、相対する非リニア画像からリニア画像を認識するために、拡張ルーチン XSolarisGetVisualGamma(1) が呼び出されます。詳細は、XSolarisGetVisualGamma(1) のマニュアルページを参照してください。

CG14 は、Creator アクセラレータのようなリニア画像を備えていません。CG14 は、特別なガンマ LUT を使用して、画面全体に影響するガンマ補正を行います。したがって、CG14 では、ガンマ補正された 24 ビットのウィンドウと補正されていないウィンドウを、画面上に同時に開くことはできません。Creator の画面上では、両方のウィンドウを同時に開くことが可能です。

単一のカラー LUT

CG14 では、ハードウェアのカラー LUT を 2 つ備えています。1 つは 8 ビットのアンダーレイ画像で使用され、もう 1 つは 8 ビットのオーバーレイ画像で使用されます。一方、Creator アクセラレータシリーズ 1 と 2 では、ハードウェアのカラー LUT を 1 つだけ備えています。これは、2 つのウィンドウのカラーマップが、同じピクセルの位置で同じ色を持っていない場合には、Creator アクセラレータ上のオーバーレイウィンドウが、8 ビットのアンダーレイウィンドウに対し、カラーマップのフラッシュ現象を起こすことを意味します。Creator シリーズ 3 には、Xserver が割り当てや共有を管理する 4 種類のカラー LUT があります。

Creator アクセラレータ上にあるカラー LUT が 1 つだけの場合には、透過オーバーレイのアプリケーション上でオーバーレイとアンダーレイが色を共有するようにプログラミングしてください。オーバーレイ画像は、アンダーレイ画像とは常に異なるため、透過オーバーレイのアプリケーションは最低 2 種類のカラーマップを必要とし、その 1 つはオーバーレイに、もう 1 つはアンダーレイに割り当てられます。オーバーレイウィンドウは、通常アンダーレイウィンドウの子ウィンドウであり、各ピクセルのレイヤー間の関係は、アプリケーションによって管理されます。このような状態で、マウスポインタがアンダーレイとオーバーレイの境界の内側にある場合には、オーバーレイのカラーマップはハードウェアのカラー LUT にインストールされますが、アンダーレイのカラーマップはインストールされません。オーバーレイのカラーマップを通して表示された際に、アンダーレイのピクセルが正しい色を表示しているかどうかを確認してください。アンダーレイとオーバーレイ両方のカラーマップの同じ位置にそれぞれ色を割り当てることによって、確認することができます。

Creator と ZX アクセラレータとの比較

ZX アクセラレータと異なり、Creator アクセラレータの出荷時のデフォルト画像はオーバーレイではありません。ZX アクセラレータでは、デフォルト画像は 8 ビットのオーバーレイの疑似カラーとなりますが、Creator アクセラレータでは、SX アクセラレータと同様に、8 ビットのアンダーレイの疑似カラーとなります。アンダーレイのウィンドウで影響を受けないポップアップウィンドウを持つアプリケーションを作成する場合には、単純にデフォルトの画像を使用することはできません。そのためアプリケーションは、影響を受けないオーバーレイ画像を検索するために、XSolarisOvlSelectBestOverlay を呼び出す必要があります。詳細は、X ウィンドウシステムのオーバーレイについて記述している、Solaris のマニュアルを参照してください。

注 -

XSolarisOvlSelectBestOverlay は、Solaris 2.4 リリースから提供されています。Solaris 2.4 と Solaris 2.4 以前のオペレーティングシステム上でアプリケーションを実行する場合には、この関数の外部参照は、#pragma weak を定義します。これにより、プログラムはシンボルの値を確認することができます。プログラムが Solaris 2.3 またはそれ以前のバージョンで実行されている場合は、シンボルの値が 0 になります。この場合には、オーバーレイ画像を検索するために XSolarisOvlSelectBestOverlay を呼び出すことはできません。そのかわりに、アプリケーションは、XGetVisualInfo を使用して、256 以下のカラーマップのエントリを持つ最初の 8 ビット画像を検索することができます。ただし、この方法は Creator アクセラレータ特有のものであり、Creator アクセラレータを使用するためのコードは、他のデバイスへの移植性があるとは限りません。

ウィンドウマネージャーについての注意事項

Creator アクセラレータのデフォルトの画像がオーバーレイでないため、オーバーレイのウィンドウがオーバーライドリダイレクトでない場合には、問題が発生することがあります (たとえば、ウィンドウマネージャの装飾ウィンドウで囲まれる場合など)。Solaris でサポートしている olwm、mwm、dtwm などのウィンドウマネージャーでは、ツールキットのサブウィンドウが、デフォルト画像の装飾ウィンドウで囲まれています。これは、アプリケーション内で、ポップアップウィンドウにデフォルト以外の画像が指定されている場合も同様です。

たとえば、デフォルトの画像が 8 ビットのアンダーレイの疑似カラーの場合に、アプリケーションがツールキットに対し、ポップアップウィンドウを 8 ビットのオーバーレイの疑似カラー画像に置くように指定しても、ウィンドウマネージャはそのポップアップウィンドウを、8 ビットのアンダーレイの装飾ウィンドウで囲みます。このように、ポップアップウィンドウは、他のアンダーレイのウィンドウに悪影響を与えます。

この問題を回避する方法を以下に示します。

ハードウェアのカラー LUT の使用方法

以下に示す画像表示形式では、カラー LUT を使用します。

カラー LUT を 1 つだけ持つ Creator アクセラレータでは、画像表示形式のカラーマップは、相互にカラーマップのフラッシュ現象を発生させます。カラーマップのフラッシュ現象を回避する方法については、「カラーマップのフラッシュ現象の削減」を参照してください。

他の Creator アクセラレータの画像表示形式では、カラー LUT のリソースを使用しないため、カラーマップのフラッシュ現象は発生しません。

カラーマップのフラッシュ現象の削減

Creator アクセラレータの 24 ビットトゥルーカラー画像は、カラーマップのフラッシュ現象を発生させずに、同時に 1600 万色以上の表示をすることができます。Creator の描画エンジンは、24 ビットの描画用に最適化されています。

一般ユーザーへの注意事項

24 ビットトゥルーカラーの画像表示形式では、カラーマップがフラッシュすることなく、高速描画をすることができます。ただし、Creator アクセラレータの出荷時のデフォルトは、8 ビット疑似カラー画像表示になっています。この出荷時のデフォルトは、24 ビットの画像表示形式では正常に機能しない X ウィンドウシステムのアプリケーションを実行するための設定です。多くのデスクトップアプリケーションは、この画像表示形式で正常に動作します。

デスクトップ上でカラーマップのフラッシュ現象を減らすには、デフォルトの画像表示形式を 24 ビットトゥルーカラーに設定してウィンドウシステムを実行する方法があります。この方法は、Creator アクセラレータ上でウィンドウシステムを実行するのに適しています。

  1. 24 ビットトゥルーカラーで OpenWindows を実行するには、以下のコマンドを入力します。 

    % openwin -dev /dev/fbs/ffb0 defdepth 24

  1. 上記のモードで CDE を実行する場合は、/usr/dt/config/Xservers ファイルを編集し、サーバーの X 起動コマンドに "defdepth 24" を追加してください。この画像表示形式を使用する際の注意点を以下に示します。

    • X ウィンドウシステムのアプリケーションには、24 ビットの画像表示形式では正常に機能しないものがあります。このようなアプリケーションでは、プログラムが実行に失敗し、BadMatch エラーメッセージを表示します。プログラムによっては、コアダンプが発生したり、正しくない色を表示したりする場合があります。このようなアプリケーションを使用する場合は、アプリケーションを 8 ビット疑似カラーをデフォルトの画像表示形式として実行しなおすことによって、問題の原因を特定することができます。この状態で正しく動作した場合には、そのプログラムが 24 ビットトゥルーカラーのデフォルト画像表示形式では機能しないことがわかります。この場合、24 ビットトゥルーカラーのデフォルト画像表示形式で動作するように、プログラムをアップグレードする必要があります。プログラムがアップグレードされるまでは、出荷時のデフォルトの 8 ビット疑似カラーの画像表示形式を使用してください。

    • デフォルトの画像表示の深さが 24 ビットの場合には、ピクセルマップおよびウィンドウのバッキングストアは、深さが 8 ビットの場合の 4 倍の領域を必要とします。これによって、サーバーの実行イメージが増大することはありませんが、スワップ領域の使用率が増大します。多くのピクセルマップやバッキングストアウィンドウを使用するプログラムでは、設定を 8 ビットモードにしてください。

開発者への注意事項

24 ビット透過モードでプログラミングを行ってください。デフォルトの画像表示形式が 24 ビットトゥルーカラーの場合は、プログラムは正常に実行されます。

24 ビット透過モードのプログラムが正常に動作しない場合には、いくつかの理由が考えられます。以下に、プログラムを正常に実行するための注意点を示します。

ウィンドウシステムの "defdepth 8" および "defdepth 24" の両方のモードで、アプリケーションプログラムをテストしてください。

ハードウェアのウィンドウ ID

ピクセルの内容を表示するために、ハードウェアのウィンドウ ID (WID) が必要となります。

注 -

ここで説明するウィンドウ ID と X プロトコルのウィンドウ ID とは異なります。X プロトコルのウィンドウ ID は、ウィンドウを識別する XID です。ハードウェアのウィンドウ ID とは、ウィンドウの外観を操作するフレームバッファーに取り込まれる値です。

オーバーレイのピクセルコードには、可視的な色を表示する不透明なピクセルとして使用されるものがあります。それ以外のオーバーレイのピクセルコードは、アンダーレイのウィンドウの表示属性を制御するために使用されます。このコードは、ハードウェアのウィンドウ ID (WID) と見なされます。カラーマップの上位のコード (255 に近いコード) のいくつかは、WID として使用されます。WID の実際の数は、ffbconfig -maxwids オプションによって設定することができます。WID として使用されるオーバーレイコード 1 つにつき、オーバーレイのカラーマップのエントリ数が 1 つ減少します。maxwids のデフォルト値は 32 のため、オーバーレイには 224 の不透明なピクセルの値が存在します。

ハードウェア WID のうちの 1 つは、常にデフォルトの画像表示形式のウィンドウ用に確保されます。それ以外の WID は、以下のウィンドウに優先度に基づいて割り当てられます。

デフォルト以外の画像表示形式のウィンドウは、同一の画像表示形式の他のウィンドウとWID を共有することができます。ただし、ダブルバッファーのウィンドウは、固有の WID を持つウィンドウのように、常に固有の WID を要求します。

上記のようなウィンドウを作成した場合には、作成可能な別の種類のウィンドウの数が減少してしまいます。使用可能なすべての WID が割り当てられてしまうと、XCreateWindow の呼び出しは失敗し、BadAlloc のエラーメッセージが表示されます。

maxwids には、2n (1、2、4、8、16、32) を指定してください。デフォルトの値は 32 です。

maxwids の値を小さくすることにより、オーバーレイの不透明なカラーピクセルの数が増加しますが、ユーザーが作成可能な XGL、ダブルバッファー、デフォルト以外の画像表示形式のウィンドウの数は減少することになります。

カーソルの使用方法

Creator アクセラレータは、ハードウェアカーソルを備えています。このカーソルの画像は、ビデオ信号の出力に直接合成されます。一方、ソフトウェアカーソルは、フレームバッファーに描画され、以前のフレームバッファーの内容は一時的に保存されます。ソフトウェアカーソルは、ハードウェアカーソルと比較して、オーバーヘッドが発生しやすくなっています。ハードウェアカーソルでは、カーソルの動きに対する応答が最適化されています。

Creator のハードウェアカーソルの最大の大きさは、64 × 64 です。幅と高さが 64 以下のカーソルには、ハードウェアカーソルを使用してください。ハードウェアカーソルを使用するよう定義されていない場合は、カーソルはソフトウェアカーソルとして描画されます。

Creator アクセラレータのソフトウェアカーソルは、オーバーレイのプレーングループに描画されます。ソフトウェアカーソルは、オーバーレイウィンドウのピクセルに影響しますが、アンダーレイウィンドウのピクセルには影響しません。

X11 のカーソルは、クライアントのアプリケーションが要求する前景と背景の色を持っています。ハードウェアカーソルの色は要求した色と一致しますが、ソフトウェアカーソルの色は要求した色の近似色となる場合があります。

注 -

Solaris の Visual グラフィックスライブラリの制限事項により、ソフトウェアカーソルが適切に削除されない場合があります。この制限事項を回避するには、DGA グラブウィンドウ上のカーソルを強制的にハードウェアカーソルにしてください (ただし、カーソルの一部が表示されなくなる場合があります)。

ハードウェアのダブルバッファリング

ハードウェアのダブルバッファリングは、MBX と XGL でサポートされます。MBX と XGL のダブルバッファリングを同時に同じウィンドウで使用することはできません。

ハードウェアのダブルバッファリングは、 Creator アクセラレータすべての構成の 8R ウィンドウで使用することができます。24 ビットのウィンドウにおけるハードウェアのダブルバッファリングは、Creator/DBZ (Creator3D) の構成でのみ有効です。8X のオーバーレイウィンドウは、Creator アクセラレータの構成では、ハードウェアのダブルバッファリングが行われることはなく、常にソフトウェアのダブルバッファリングが行われます。

MBX を介してダブルバッファリングを行うには、WID が 1 つ必要です。これにより、作成できる WID を必要とするウィンドウの数が減少します。詳細は、「ハードウェアのウィンドウ ID」を参照してください。使用可能な WID がない場合には、MBX はソフトウェアのバッファリングに戻ります。ソフトウェアのバッファリングでは、バッファーの交換 (フリップ) のために、バックバッファーピクセルマップからウィンドウにコピーされたデータが使用されます。

MBX では、バッファーの交換 (フリップ) は同時に発生します。サーバーへの要求は、モニターの垂直帰線期間が発生して、バッファーの交換が発生するまで応答されません。 X11 のクライアントは、処理を続行してサーバーに要求を送ることが可能ですが、バッファーの交換が終了するまではそれらの要求は処理されません。

デバイスの設定

/usr/sbin/ffbconfig を実行することにより、Creator アクセラレータのモニター表示モード、デフォルト画像表示形式、デフォルトのリニア順、WID の数を変更することができます。詳細については、ffbconfig(1M) のマニュアルページを参照してください。

モニターが立体表示モードに設定されていない場合には、DGA を介して立体表示を行うことはできません。

ffbconfig によって、共有の OWconfig ファイルを更新する際に、/usr/openwin ディレクトリが遠隔マウントされている場合は、エラーが発生する可能性があります。ffconfig が、setuid により root の権限で実行可能となっている場合でも、同様にエラーが発生します。このエラーは、UNIX 上ではローカルマシンのルートユーザーが、遠隔マシンのルートユーザーとは異なるために発生するものです。これを回避するには、遠隔マシンにログインして ffbconfig を実行してください。

製品仕様について

この節では、様々なアプリケーション上で動作する Creator グラフィックスアクセラレータの製品仕様について説明します。

Direct Xlib

Direct Xlib は、Creator アクセラレータではサポートされていません。Direct Xlib の代わりに、X 共有メモリー転送機能（Solaris 2.5 の新機能）を使用してください。共有メモリーを転送するには、クライアント環境に以下の環境変数を設定してください。 

setenv DISPLAY :0
setenv XSUNTRANSPORT shmem 
setenv XSUNSMESIZE 512

注 -

setenv XSUNSMESIZE 512 では、クライアントが要求するバッファーの大きさを 512KB に指定しています。これ以外の大きさを指定することも可能ですが、転送速度とシステムが消費するメモリー量を考慮すると 512KB が適切な値となります。

フレームバッファーに高速ピクセル転送をする際に、XPutImage と Direct Xlib を使用するアプリケーションでは、代わりに、MITSHM 拡張機能の XShmPutImage を Creator アクセラレータ上で使用するようにしてください。この機能を使用することにより、X サーバーと同一のマシン上で作業を行う場合に、ピクセルの高速転送が可能になります。

24 ビットの画像に XShmPutImage を使用している場合には、共有メモリーの割り当て量を、デフォルトで設定されている量よりも大きくする必要があります。詳細は「X11perf のベンチマークテスト」で説明します。

X11perf のベンチマークテスト

デフォルトのサーバーの画像が 24 ビットトゥルーカラーの場合に、X11perf のベンチマークテストを行うと、-shmput<nn> テストが実行に失敗します。これは、 -shmput<nn> テストでは、デフォルトの shmsys 設定で割り当てられた共有メモリーよりも、多くのメモリーを必要とするためです。X11perf の X11R5 バージョンの場合はコアダンプが発生しますが、X11R6 バージョンの場合は、エラーが表示されて測定は実行されません。

-shmput<nn> テストを実行する場合は、共有メモリーの量を増やす必要があります。

  1. メモリーの量を変更するには、/etc/system に以下の行を追加します。 

    set shmsys:shminfo-shmmax=8192000

Creator でのピクセルコピー用ハードウェアの不在

Creator アクセラレータには、フレームバッファー内にピクセルをコピーするハードウェアが存在しません。ピクセルのコピーは、CPU レジスタにピクセルを読み込み、その後にフレームバッファーに再び書き込むという方法で行われます。このように、フレームバッファー内でのピクセルのコピーは、主に CPU で行われます。システムの負荷が大きいと、ウィンドウでのドラッグ操作の性能が低下する場合があります。たとえば、SunVideo ストリームを実行中に、ShowMe Whiteboard の "Snap Region" での画像ドラッグ操作の速度が低下する場合があることなどです。一方、TurboGX アクセラレータにはピクセルをコピーするハードウェアが存在するため、このように処理速度が低下することはありません。

背景の設定が None の場合に発生する一時的なカラー障害

イメージツールのイメージパレットウィンドウを、マウスのセレクトボタンを使用してイメージツールのメインウィンドウへ移動させると、メインウィンドウが一時的にシアン色になる場合があります。この状態はすぐに修復されますが、ユーザーが見て気づく程度に持続します。この現象は、ドラッグするウィンドウが部分的にイメージツールの内側に入っている場合に発生するものです。これは、イメージツールのメインウィンドウが XView の WIN_TRASPARENT ウィンドウであり、対応する X ウィンドウの背景が None に設定されているためで、背景が None に設定されている場合には、アプリケーションは重なっているウィンドウが移動した後で、障害のある部分を修復します。クライアントが障害のあるイベントを処理し、描画要求を送信する必要があるために、この障害修復作業には多少時間がかかります。

イメージツールのイメージパレットウィンドウは、8 ビット のウィンドウです。ピクセルデータは、Creator アクセラレータの赤のチャネルにあります。8 ビットウィンドウの背景のピクセル値は、通常、0×02 という小さな値です。赤のチャネルにあるピクセルデータは、緑のチャネルや青のチャネルにあるデータに悪影響を与えることはありません。メインウィンドウの背景は、白 (0xfffff) ですが、8 ビットの ウィンドウが重なっている場合には、ピクセル値が 0xffff02 になります。

8 ビットウィンドウが重なっている場合は、その領域は 8 ビットウィンドウとして表示されます。8 ビットウィンドウを移動させるとすぐに、サーバーはその領域が 24 ビットウィンドウとして表示されるように、ウィンドウ ID を変更します。この処理の後に背景が修復されるため、一時的にこの領域にあった以前のピクセル値 (0xffff02) が、24 ビットのピクセル表示となります。このピクセル値は、青と緑として表示されるため、結果的にシアンとして表示されます。

注 -

SX フレームバッファー上でも同様の現象が見られます。ただし、SX フレームバッファーは、8 ビットの ウィンドウを青のチャネルに格納するため、一時的に表示される背景は、緑と赤で黄色となります。

黄色と白の色の違いは識別しにくいため、SX フレームバッファーでは、ユーザーがこの現象に気付くことはほとんどありません。ただし Creator アクセラレータ上のシアンと白の違いは、より顕著に見られます。ドラッグするウィンドウの一部分がイメージツールウィンドウの外側にある場合は、この状態が解消されるまでに多少時間がかかります。これは Creator のハードウェアが SX フレームバッファーと比較して、保持する描画状態を多く持ち、またイメージツールのウィンドウの外側にドラッグした場合、ウィンドウマネージャーによってイメージツールのウィンドウのヘッダーが常に変更されるためです。さらにテキストの描画操作の間にコピー操作が行われる原因にもなり、描画操作とコピー操作は異なる描画状態を使用するため、Creator のハードウェアコンテキストに対する描画状態の読み込み・書き込みは連続的に行われる必要があり、Creator 上でのカラー領域の修復に要する時間は、SX と比較して長くなります。

上記の例では、イメージツールでの場合に特定して説明しましたが、背景が None に設定してあるウィンドウであれば、どの X ウィンドウでも同様です。(バグ ID 1215303)。

上記に示したような一時的なカラー障害は、背景が None に設定されているウィンドウに共通して発生します。この状態を回避するために、この種のウィンドウを使用しているアプリケーションでは、None 以外の背景を設定してください。X サーバーでは、このようなカラー障害を、発生後ただちに修復することができます。