製品仕様について

この節では、様々なアプリケーション上で動作する 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 サーバーでは、このようなカラー障害を、発生後ただちに修復することができます。