第 6 章 透明オーバーレイウィンドウ
この章では、Solaris OpenWindows 環境で透明オーバーレイウィンドウ機能を提供する、透明オーバーレイ拡張機能アプリケーションプログラミングインタフェース (API) について説明します。
-
オーバーレイウィンドウと標準 X ウィンドウの違い
-
オーバーレイウィンドウの作成方法と描画方法
-
透明オーバーレイウィンドウを使用するアプリケーションについて、さまざまなデバイスへの移植性を保証する方法
注 –
ハードウェアでサポートされている場合はサーバーオーバーレイを使用することをお勧めします。サーバーオーバーレイは FFB デバイス上でサポートされます。サーバーオーバーレイについての詳細は、第 5 章「サーバーオーバーレイウィンドウ」を参照してください。
透明オーバーレイウィンドウとは
透明オーバーレイ拡張機能により、透明オーバーレイウィンドウを作成し、操作できます。このようなウィンドウは、ピクセル単位で操作することによりユーザーが背景のウィンドウを見ることができる X ウィンドウです。透明オーバーレイウィンドウを作成し、使用する機能はソフトウェアに実装されているので、特別なハードウェアは不要です。単純なハードウェア上で複雑な透明オーバーレイを操作するには時間がかかりますが、X サーバーが使用可能であれば特殊なオーバーレイハードウェアが使用できるので、クライアントは正しいビジュアルを選択します。ハードウェアやニーズによっては、透明オーバーレイウィンドウに合わせてクライアントのカラー割り当てを調整しなければならないことがあるので注意してください。
オーバーレイウィンドウを使用すると、アプリケーションの表示ウィンドウに一時イメージを表示できます。オーバーレイを提供するアプリケーションのユーザーは、イメージにテキストや図表の注釈を付けたり、イメージの一部分を一時的に強調表示したり、イメージの上に動画を作成したりできます。オーバーレイ上のグラフィックスを消去しても、その下にあるグラフィックを生成し直す必要はありません。
透明オーバーレイ拡張機能により、クライアントは標準 X 要求を使用して不透明ペイントまたは透明ペイントでプリミティブを描画できます。不透明ペイントは標準的な描画方法の名称で、透明ペイントはピクセルを隠します。ペイント型は、標準 X グラフィックスコンテキストに関連付けられています。ウィンドウの背景も透明ペイントに設定できます。透明オーバーレイウィンドウは、すべての正規ウィンドウ規則と操作手順に準拠しています。たとえば、透明オーバーレイウィンドウは、それが関連付けられているハードウェアに関係なく、ウィンドウの重なり順序のどこにでも配置できます。これは、Solaris X サーバーの複数プレーングループ (MPG) 機能と一緒にソフトウェアに実装されています。
サーバーの複数プレーングループ機能により、異なるハードウェアから表示されるウィンドウを共存させることができます。各ウィンドウにはビジュアルが関連付けられており、ビジュアルはハードウェアに関連付けられています。一部のハードウェアは「層」の数が限定されるように物理的に作成されていますが (たとえば、ハードウェアのオーバーレイプレーン内で作成されたウィンドウは、常に正規ウィンドウの上に表示されるものと想定される)、MPG はソフトウェア内でこの制限を解決します。MPG により、ウィンドウの重なり順序はハードウェアの物理的制限の影響を受けなくなります。その結果、重なりは単に標準サーバー内と同じになります。オーバーレイハードウェアが使用可能であり、要求される場合は、MPG によって作業を最小限度に抑え性能を高めることができます。
一般に、オーバーレイはグラフィックスを描画できるピクセルバッファ (物理的またはソフトウェアによりシミュレート) です。オーバーレイが物理的なものである (つまり、ソフトウェアでシミュレートされたものではない) 場合は、オーバーレイ上のグラフィックスを消去しても、その下にあるグラフィックスは損傷を受けません。このため、下にあるグラフィックスが複雑で再描画に時間がかかる場合は、性能の向上に役立ちます。オーバーレイがソフトウェアに含まれる場合は、オーバーレイ上のグラフィックスを消去すると Expose イベントが生成されることがあります。
透明オーバーレイウィンドウの基本的な特性
透明オーバーレイウィンドウは、ピクセルを透明に描画できる X InputOutput ウィンドウの特殊なクラスです。透明オーバーレイウィンドウのハンドルは、X ウィンドウの型 Window を持っています。標準の X ウィンドウと同様に、オーバーレイウィンドウは描画可能であり、オーバーレイウィンドウのハンドルは Drawable を取る任意の Xlib 描画ルーチンに渡すことができます。
透明オーバーレイウィンドウによって、ペイント型の属性を含むグラフィックコンテキスト属性のセットが拡張されました。透明オーバーレイ拡張機能を使用すると、不透明ペイントまたは透明ペイントを使用して透明オーバーレイウィンドウを描画できます。
ペイント型
標準 X InputOutput ウィンドウや他のドロアブル (ピックスマップなど) には不透明ペイントしか使用できませんが、透明オーバーレイウィンドウでは透明ペイントを使用してピクセルを描画できます。ペイントされた有効なピクセル値により、背後のウィンドウ内のピクセルは不透明に隠されます。このようなピクセルには、表示されるカラー値が関連付けられています。透明に描画されたピクセルは固有のカラーを持たず、下にあるピクセルから表示カラーを継承します。
不透明にペイントされたピクセルに有効なピクセル値は、XAllocColor() または別の標準ピクセル割当メカニズムを介して取得されます。ビジュアルに有効なカラーマップエントリの範囲外の値など、有効でないピクセル値を使用して不透明にペイントすると、透明オーバーレイウィンドウの場合も標準 X InputOutput ウィンドウの場合も結果は不定になります。
ペイント型は、データ構造体 XSolarisOvlPaintType で定義されます。デフォルトでは、GC のペイント型は不透明です。XSolarisOvlPaintType データ構造体は次のように定義されます。
typedef
enum { XSolarisOvlPaintTransparent, XSolarisOvlPaintOpaque, }
XSolarisOvlPaintType;
可視性
透明オーバーレイウィンドウは、すべてのピクセルが透明であっても可視的であるとみなされます。透明オーバーレイウィンドウ内の完全に透明な可視ピクセルについては、その下にあるアンダーレイのピクセルが表示されます。
オーバーレイウィンドウがアンマップされたり移動されたりすると、その下のアンダーレイがエクスポージャーイベントを受け取る場合があります。たとえば、このような状況は、異なるプレーングループ内にあるオーバーレイウィンドウとアンダーレイウィンドウを同時に表示することができないデバイス上で発生します。
透明オーバーレイウィンドウのその他の特性
ほとんどの場合、透明オーバーレイウィンドウは標準 X InputOutput ウィンドウと似ています。特に、透明オーバーレイウィンドウには次のような特性があります。
-
オーバーレイウィンドウに対してもマップとアンマップができます。そのために、XMapWindow、XUnmapWindow、XMapSubwindows、XUnmapSubwindows の各ルーチンが利用できます。
-
オーバーレイウィンドウは独自のカーソルを所有するか、親ウィンドウのカーソルを使用します。すなわち、XDefineCursor と XUndefineCursor は、オーバーレイウィンドウにも適用されます。
-
オーバーレイウィンドウは、XQueryTree の出力に表示されます。
-
ウィンドウ属性の event_mask と do_not_propogate_mask は、正常に動作します。オーバーレイウィンドウは、任意の型のイベントを処理の対象とすることができます。
-
XTranslateCoordinates と XQueryPointer は、オーバーレイウィンドウに適用されます。
-
標準の X ウィンドウについては、save_under が適用されます。
-
標準の X ウィンドウについては、override_redirect が適用されます。
また、透明オーバーレイウィンドウには、ウィンドウを固有のものにする特性があります。以下の節ではこのような特性について説明します。
背景
X 仕様で定義されているように、ウィンドウには背景を設定できます。ウィンドウの背景の主な目的は、クライアントがウィンドウの露出領域を再描画するのに時間がかかる場合に、何か適当なものをその領域に表示することです。ウィンドウが Expose イベントを受信する度に背景が描画されます。背景が描画された後で、Expose イベントがクライアントに送信されます。クライアントが XClearArea 要求または XClearWindow 要求を発行したときにも背景が描画されます。
標準の X InputOutput ウィンドウと同様に、透明オーバーレイウィンドウにも背景を設定できます。通常のウィンドウと同様に、透明オーバーレイウィンドウの背景は、Expose イベント、XClearArea 要求、XClearWindow 要求に応答して描画されます。標準タイプの背景 (None、pixmap、pixel、ParentRelative) の他に、透明オーバーレイウィンドウでは transparent という新しいタイプの背景を設定することもできます。透明 (transparent) の背景を指定する場合は、XSolarisOvlSetWindowTransparent という新しいルーチンを使用します。
デフォルトでは、透明オーバーレイウィンドウの背景は透明ですが、アプリケーション内では、表 6–1に示されているように、通常の X タイプの背景 (None、ピックスマップ XID、ピクセル値、ParentRelative) を指定することもできます。
表 6–1 透明オーバーレイウィンドウの背景値|
背景 |
説明 |
|---|---|
|
透明 |
透明オーバーレイウィンドウの背景はデフォルトで透明に描画される。 |
|
なし |
オーバーレイウィンドウ内で背景の描画を起動する条件が検出されると、描画は実行されない。透明ペイントも不透明ペイントも描画されない。 |
|
ピックスマップ ID |
背景は不透明ペイントで描画される。描画されるピクセル値は X 仕様で定義されたピックスマップから継承される。 |
|
単一のピクセル値 |
背景は不透明ペイントで一様なペイントのカラーで描画される。 |
|
ParentRelative |
ParentRelative の背景の動作は、親ウィンドウの背景とタイプによって異なる。親ウィンドウがアンダーレイである場合、オーバーレイウィンドウである子の背景は不透明ペイントで描画され、ピクセルは X 仕様の定義に従って描画される。親ウィンドウがオーバーレイの場合、オーバーレイウィンドウの子の背景は、その親ウィンドウの背景と同じになり、透明ペイントまたは不透明ペイントで描画される。 |
XSolarisOvlSetTransparent を使用してオーバーレイ以外のウィンドウの背景を設定しようとすると、BadMatch エラーが発生します。アンダーレイウィンドウの背景が ParentRelative であり、親ウィンドウが透明な背景を持つオーバーレイである場合、アンダーレイウィンドウである子は None の背景を持つものとして取り扱われます。
ウィンドウの境界
オーバーレイウィンドウの境界は不透明です。境界は常に不透明なペイントで描画されます。標準の X InputOutput ウィンドウと同様に、境界の幅は XSetWindowBorderWidth を使用して制御することができます。
バッキングストア
バッキングストアはオーバーレイウィンドウについては無効です。
ウィンドウのグラビティ
ビットとウィンドウのグラビティ属性 (bit_gravity と win_gravity) は透明オーバーレイウィンドウにも適用されますが、グラビティによってピクセルの移動が必要になる場合は、ピクセルのカラー情報とともに透明かどうかという情報も移動されます。
カラーマップ
オーバーレイのカラーマップは、X の規則に従ってインストールされます。ピクセルを共有するオーバーレイ/アンダーレイのペアをアプリケーション内で使用する場合は、各ウィンドウごとに 1 つのカラーマップを作成してください。ピクセルを共有するウィンドウの問題については、オーバーレイ/アンダーレイに使用するビジュアルの選択と アプリケーションの移植性の設計を参照してください。
オーバーレイ/アンダーレイのペアがハードウェアカラー LUT を共有しないことがわかっている場合は、それらの両ウィンドウに別々のカラーマップを安全に割り当てることができ、カラーマップフラッシングは発生しません。
注 –
アプリケーションの移植性を高め、カラーのフラッシングを最小限に抑えるために、オーバーレイとアンダーレイのカラーマップ内で同じカラーを使用してください。それができない場合は、フラッシングを発生させることなく異なるカラーマップを割り当てられるかどうかを、ビジュアル問い合わせルーチンを使用して調べてください。
入力配送モデル
オーバーレイウィンドウは、標準の X ウィンドウと同様にイベントを処理の対象とすることができます。オーバーレイウィンドウは、その実際に目に見える範囲内で発生する任意のイベントを受信します。イベントが発生する位置のピクセルのペイント型は問題ではありません。たとえば、オーバーレイウィンドウがウィンドウ進入イベントを処理の対象としている場合に、ポインタがウィンドウの実際に目に見える範囲内に入ると、ピクセルが透明であっても不透明であっても、オーバーレイウィンドウはウィンドウ進入イベントを受信します。
このことは、アプリケーション内でグラフィカルオブジェクトの対話的なピッキング (選択) をどのように実装するかという問題に影響を与えます。すなわち、アンダーレイウィンドウに描画されたグラフィカルオブジェクトの上にあるオーバーレイウィンドウに対して、別のグラフィカルオブジェクトを描画するアプリケーションは、オーバーレイウィンドウ内またはアンダーレイウィンドウ内のどちらかのイベントを処理の対象とする必要がありますが、その両方のウィンドウ内のイベントを処理の対象とする必要はありません。入力イベントを受け取ったアプリケーションは、オーバーレイ/アンダーレイの階層構造に関する知識を利用して、どちらのグラフィカルオブジェクトが選択されたかを確定しなければなりません。
たとえば、アプリケーションがアンダーレイウィンドウ内のイベントを処理の対象としていると想定します。このアプリケーションが座標 (x,y) でイベントを受信すると、まず最初にオーバーレイ内のその座標にグラフィカルオブジェクトが存在するかどうかが調べられます。存在すれば、そこで探索処理は終了します。存在しなければ、アプリケーションは、アンダーレイ内のその座標にグラフィカルオブジェクトが存在するかどうかを確認しなければなりません。
印刷用イメージの取り出し
グラフィカルイメージが X ウィンドウに描画されると、ユーザーはウィンドウの表示内容を取り出してプリンタに送信し、ハードコピーを取ることができます。そのための最も一般的な方法は、画面のダンプを実行することです。すなわち、XGetImage を使用してウィンドウピクセルを読み取り、そのイメージをプリンタに送信します。印刷ページのサイズにイメージを合わせるために、イメージの拡大・縮小が必要になる場合もあります。このため、イメージ内にピクセル単位の拡大・縮小によるがたつきが生じることがあります。
X11 の利用者の間で一般的になりつつあるもう一つの方法は、特殊なプリンタグラフィックス API を通じてグラフィックスを再描画することです。この API は標準の Xlib グラフィックスコールをサポートし、これらの関数呼び出しをページ記述言語 (PDL) 形式に変換して適切なプリントスプーラに送信します。この方法の利点は、走査変換が適用された後のピクセルではなく座標自身を拡大・縮小することによって、グラフィックスを印刷ページに合わせられることです。したがって、イメージのがたつきが最小限に抑えられます。
ただし、プリンタ API を使用する方法は、オーバーレイ/アンダーレイウィンドウのペアに適用するときには重大な障害があります。大部分の PDL では、不透明なペイントの概念だけがサポートされ、透明なペイントはサポートされません。たとえば PostScript PDL の場合、以前に出力されたピクセルは新たに出力されたピクセルによって常に置き換えられます。このような制限があるため、プリンタ API を使用する方法では、オーバーレイ/アンダーレイウィンドウの組み合わせ中のイメージを完全に取り出せるとは限りません。特に、オーバーレイの背景が完全に透明で、不透明なペイントだけがそれに描画されるような特殊なアプリケーションでは、アンダーレイが最初に出力された後、オーバーレイが 出力されます。ただし、透明なペイントがオーバーレイに描画されて、そのオーバーレイ内の他の不透明なペイントが消去されると、上記の仕組みはうまく動作しません。
このような問題が解決されるまでは、XReadScreen と拡大・縮小処理を使用して、オーバーレイウィンドウ内のイメージの取り出しとプリンタへの送信を行ってください。あるいは、プリントする予定の情報を描画するときは、オーバーレイを使用しないでください。
オーバーレイ/アンダーレイに使用するビジュアルの選択
Solaris 透明オーバーレイ API では、複数プレーングループ (MPG) デバイスと単一プレーングループ (SPG) デバイスがサポートされます。表示デバイスにはさまざまな構成があります。表示デバイスによっては、複数プレーングループを持つものがあります。複数のハードウェアカラールックアップテーブル (LUT) を持つものもあります。また、特定のプレーングループ専用にカラー LUT を使用するものもあれば、複数のプレーングループ間でカラー LUT を共有するものもあります。このような広範な構成のために、アプリケーション開発者が移植性のあるオーバーレイアプリケーションを作成するのが困難になっています。
特定のタイプのアンダーレイウィンドウについては、高性能の描画能力を持つオーバーレイウィンドウが、特定のデバイスによって提供される場合がありますが、それより描画速度の遅い従来のオーバーレイウィンドウを提供するデバイスもあります。デバイスの中には、数多くのカラーを持つオーバーレイをサポートできるものもあればサポートできないものもあります。また、すべてのタイプのオーバーレイとアンダーレイのカラーを同時に表示できるデバイス、特定のオーバーレイ/アンダーレイの組み合わせについてはカラーの同時表示ができないデバイス、カラーの同時表示に若干の制限があるデバイスなどがあります。これらのデバイスは、複数のハードウェアカラー LUT をサポートします。ただし、ハードウェア内のカラー LUT の数が足りないために、アプリケーションによってはカラーを同時に表示できない場合があります。
Solaris Visual Overlay Window API では、アプリケーションがオーバーレイ/アンダーレイの最適なビジュアルの組み合わせについてシステムと折衝できるように、次の 2 つのユーティリティルーチンが提供されています。
-
XSolarisOvlSelectPartner
-
XSolarisOvlSelectPair
これらのルーチンについての詳細は、アプリケーションの移植性の設計を参照してください。
システムとの折衝では、各アプリケーションについて、ウィンドウとカラーの理想的な構成があることが前提とされます。アプリケーションはまず最初に、オーバーレイ/アンダーレイの「最適な」組み合わせを要求します。最初は理想的なペアを要求するという点で、アプリケーションは「最適」の定義について非常に大胆です。この要求がデバイスによって満足されれば、折衝は成立し、アプリケーションは選択されたオーバーレイ/アンダーレイのビジュアルに基づいてウィンドウを作成します。要求を満たすビジュアルの組み合わせが存在しない場合、アプリケーションは要求を緩和し、「2 番目に最適な」組み合わせを指定します。たとえば、アプリケーションは表示可能な色数の少ないビジュアルを選択したり、特定のビジュアルについては要求する描画性能水準を落としたりします。このような手続きは、満足のゆくビジュアルが見つかるか、特定の条件が満たされない現在の環境で実行するのは意味がないとアプリケーションが判断するまで続けられます。
透明オーバーレイ API には、アプリケーションがこのような折衝を単一のサブルーチン呼び出しで実行できるようにするルーチンがあります。アプリケーションは、オーバーレイビジュアルとアンダーレイビジュアルの一方またはそれら両方について満足する条件を指定します。広範囲のグラフィックス装置に対する移植性を保障するために、アプリケーション内ではこれらのルーチンを使用することをお薦めします。
プログラム例
以下のプログラムは、透明オーバーレイの単純な例を示しています。このプログラムは透明オーバーレイウィンドウを作成し、ウィンドウのボーダを白で描画し、テキスト文字列を白で表示し、白で塗りつぶされた矩形を描画します。ペイント型はデフォルトで不透明に描画され、ウィンドウの背景はデフォルトで透明に描画されます。次の Makefile を使用して、このプログラムをコンパイルし、リンクしてください。
simple: simple.c cc -I../ -I/usr/openwin/include -o simple simple.c \ -L/usr/openwin/lib -lX11 -lXext
例 6–1 透明オーバーレイのプログラム例
#include <stdio.h> #include
<X11/Xlib.h> #include “X11/Xmd.h” #include
<X11/extensions/transovl.h> #include
<X11/extensions/transovlstr.h> Display *display; Window
window; XSetWindowAttributes attribs; GC gc; XGCValues
gcvalues; main() { display = XOpenDisplay(““);
attribs.override_redirect = True;
attribs.border_pixel = WhitePixel(display,0);
window = XSolarisOvlCreateWindow(display, DefaultRootWindow(display),
100, 100, 500, 500, 10, CopyFromParent, InputOutput, CopyFromParent,
CWBorderPixel | CWOverrideRedirect, &attribs); gcvalues.font =
XLoadFont(display, “fixed”);
gcvalues.foreground = WhitePixel(display, 0);
gc = XCreateGC(display, window, GCFont | GCForeground, &gcvalues);
XMapWindow(display, window); XDrawString(display, window,
gc, 50, 50, “This is a test”, 14);
XFillRectangle(display, window, gc, 70, 70, 100, 100);
XFlush(display); while (1);}
Solaris 透明オーバーレイウィンドウ API の概要
透明オーバーレイウィンドウ API には、表 6–2に示すルーチンが含まれています。これらのルーチンは libXext.so によって提供されます。Solaris オーバーレイルーチンを使用するには、次の操作を実行してください。
-
/usr/openwin/include/X11/extensions/transovl.h ファイルをインクルードする。
-
/usr/openwin/lib/libXext.so ライブラリにライブラリのデバイスハンドラをリンクする。
| 名前 | 説明 |
|---|---|
|
XSolarisOvlCreateWindow |
オーバーレイウィンドウを作成する。 |
|
XSolarisOvlIsOverlayWindow |
ウィンドウがオーバーレイウィンドウかどうかを示す。 |
|
XSolarisOvlSetPaintType |
後続の Xlib 描画によって描画されるペイントの型を指定する。 |
|
XSolarisOvlGetPaintType |
現在のペイント型を取得する。 |
|
XSolarisOvlSetWindowTransparent |
オーバーレイウィンドウの背景の状態を透明に設定する。 |
|
XSolarisOvlCopyPaintType |
ソースドロアブル内のピクセルのペイント型属性に基づいて、宛先ドロアブルに不透明ペイントと透明ペイントを描画する。 |
|
XSolarisOvlCopyAreaAndPaintType |
あるドロアブルのペアから別のペアに領域とペイント型をコピーする。 |
|
XReadScreen |
画面の矩形に表示されるカラーを戻す。 |
|
XSolarisOvlSelectPartner |
既存のビジュアルに最適のオーバーレイビジュアルまたはアンダーレイビジュアルを戻す。 |
|
XSolarisOvlSelectPair |
オーバーレイビジュアルとアンダーレイビジュアルに定義された基準セットに最適のオーバーレイ / アンダーレイのペアを選択する。 |
この章の残りの節では、透明オーバーレイ API のルーチンについて説明します。
透明オーバーレイウィンドウの作成
XSolarisOvlCreateWindow を使用すると、透明オーバーレイウィンドウを作成できます。このルーチンは、XCreateWindow と同様に動作しますが、生成されるのは透明オーバーレイウィンドウです。新しく作成されたウィンドウを不透明ペイントと透明ペイントで描画でき、オーバーレイウィンドウの背景は透明になります。
XSolarisOvlCreateWindow の class 引数は、InputOutput にする必要があります。オーバーレイウィンドウは InputOnly ウィンドウとして作成できますが、その場合は標準 InputOnly ウィンドウと同様に動作します。オーバーレイと非オーバーレイに違いがあるのは、InputOutput ウィンドウだけです。
XSolarisOvlCreateWindow の構文と引数を次に示します。
Window XSolarisOvlCreateWindow(Display *display, Window parent, int x, int y, unsigned int width, unsigned int height, unsigned int border_width, int depth, unsigned int class, Visual * visual, unsigned long valuemask, XSetWindowAttributes * attr)
このルーチンの引数は、XCreateWindow と同じです。
表 6–3|
display |
X サーバーへの接続を指定する。 |
|
parent |
親ウィンドウを指定する。 |
|
x, y |
ウィンドウの左上隅のピクセルの座標を親ウィンドウに対する相対座標で指定する。 |
|
width, height |
ウィンドウの幅と高さをピクセル単位で指定する。 |
|
border_width |
ウィンドウの境界の幅をピクセル単位で指定する。 |
|
depth |
ウィンドウのデプスを指定する。 |
|
class |
ウィンドウのクラスを指定する。クラスが InputOutput でない場合、ウィンドウはオーバーレイウィンドウにはならない。 |
|
visual |
ウィンドウのビジュアル構造体へのポインタを指定する。 |
|
valuemask |
attr 引数でどのウィンドウ属性を定義するかを指定する。 |
|
attr |
ウィンドウ属性を指定する。 |
任意のビジュアルを使用してオーバーレイを作成できます。ただし、どのオーバーレイ / アンダーレイのペアでも最適であるとは限りません。画面ごとに、最適のオーバーレイ / アンダーレイビジュアルのペアのセットを定義します。これらは、特定のアンダーレイビジュアルを使用して作成できるオーバーレイウィンドウの最適のビジュアルを定義します。また、特定のオーバーレイビジュアルを使用して作成できるアンダーレイウィンドウの最適のビジュアルも定義します。XSolarisOvlSelectPair と XSolarisOvlSelectPartner を使用すると、最適のペアを設定できます。
「最適」の定義はデバイスごとに異なりますが、通常はデバイスでアンダーレイウィンドウとは異なるプレーングループ内にオーバーレイウィンドウを作成できるかどうかを指します。オーバーレイ / アンダーレイビジュアルのペアについての詳細は、オーバーレイ/アンダーレイビジュアルの最適なペアの選択を参照してください。
オーバーレイウィンドウは、Xlib ルーチンである XDestroywindow または XDestroySubwindows によって削除されます。
グラフィックスコンテキストのペイント型の設定
XSolarisOvlSetPaintType ルーチンを使用して、GC のペイント型を設定できます。XSolarisOvlSetPaintType では、指定された GC を使用して後続の Xlib 描画によって描画されるペイントの型を指定します。このルーチンは、この GC を使用する Xlib 描画ルーチンによってオーバーレイウィンドウ上に不透明ピクセルが生成されるか、透明ピクセルが生成されるかを制御します。指定したペイント型は、このルーチンの別の呼び出しによって変更されるまで、GC に適用されます。ペイント型属性は、前景と背景の GC 属性に適用されます。構文と引数を次に示します。
void XSolarisOvlSetPaintType (Display *display, GC gc, XSolarisOvlPaintType paintType)
|
display |
X サーバーへの接続を指定する。 |
|
gc |
対象の GC を指定する。 |
|
paintType |
指定された GC を使用して、以降の Xlib 描画ルーチンで描画されるペイントの型を指定する。 |
paintType の値として、XSolarisOvlPaintOpaque、 XSolarisOvlPaintTransparent のどちらかを指定できます。
-
paintType の値が XSolarisOvlPaintOpaque の場合は、指定された GC を使用する Xlib 描画ルーチンで生成されるピクセルは不透明になります。したがって、下にあるピクセルは上のピクセルによって隠されます。これは、デフォルトです。
-
paintType の値が XSolarisOvlPaintTransparent である場合は、指定された GC を使用する Xlib 描画ルーチンで生成されるピクセルは透明になります。したがって、下にあるピクセルの色が表示されます。
透明オーバーレイウィンドウの背景の設定
XSolarisOvlSetWindowTransparent ルーチンを使用して、透明オーバーレイウィンドウの背景状態を透明に設定できます。この要求の後に描画される背景は、すべて透明になります。背景状態を他の値に変更するには、XChangeWindowAttributes()、XSetWindowBackground()、または XSetWindowBackgroundPixmap() のいずれかを使用します。
XSolarisOvlSetWindowTransparent の構文と引数を次に示します。
void XSolarisOvlSetWindowTransparent (Display *display, Window w)
|
display |
X サーバーへの接続を指定する。 |
|
w |
透明オーバーレイウィンドウを指定する。 |
注 –
w が透明オーバーレイウィンドウでない場合は、BadMatch エラーが発生します。
透明オーバーレイウィンドウへの描画
透明オーバーレイウィンドウの作成が終わったら、XDrawLines や XFillRectangles など、すべての標準 Xlib プリミティブ描画ルーチンを使用してウィンドウに描画できます。透明オーバーレイウィンドウに描画するときには、GC のペイント型属性を使用して、描画されるピクセルの品質が制御されます。ペイント型属性は、前景と背景の GC 属性に適用されます。ペイント型を設定するには、XSolarisOvlSetPaintType ルーチンを使用します。このルーチンについての詳細は、グラフィックスコンテキストのペイント型の設定を参照してください。
GC のペイント型は、XPutImage で描画されるピクセルの型も制御します。引数 GC のペイント型が XSolarisOvlPaintOpaque の場合は、ソースイメージからのカラー情報が使用され、ピクセルは不透明ペイントで描画されます。ただし、ペイント型が XSolarisOvlPaintTransparent の場合は、ソースカラー情報が無視され、ピクセルは透明ペイントで描画されます。
ペイント型が XSolarisOvlPaintTransparent である GC を使用して、アンダーレイウィンドウやピックスマップなど、透明オーバーレイウィンドウ以外のドロアブルに描画する場合は、GC ペイント型が無視され、ピクセルは不透明ペイントで描画されます。
透明オーバーレイウィンドウの特性の問い合わせ
XSolarisOvlIsOverlayWindow ルーチンを使用して、ウィンドウがオーバーレイウィンドウかどうかを判断できます。また、XSolarisOvlGetPaintType ルーチンを使用して、GC の現在のペイント型を判断できます。
ウィンドウがオーバーレイウィンドウかどうかの判断
XSolarisOvlIsOverlayWindow ルーチンを使用して、ウィンドウがオーバーレイウィンドウかどうかを判断できます。このルーチンは、指定されたウィンドウ w がオーバーレイウィンドウの場合は True を戻し、それ以外の場合は False を戻します。
Bool XSolarisOvlIsOverlayWindow (Display *display, Window w)
|
display |
X サーバーへの接続を指定する。 |
|
w |
ウィンドウを指定する。 |
グラフィックスコンテキストのペイント型の判断
XSolarisOvlGetPaintType ルーチンは、GC の現在のペイント型を戻します。
XSolarisOvlPaintType XSolarisOvlGetPaintType (Display *display, GC gc)
|
display |
X サーバーへの接続を指定する。 |
|
gc |
問い合わせ対象の GC を指定する。 |
ピクセル転送ルーチン
透明オーバーレイ API は、次の 3 つのピクセル転送ルーチンを提供します。
-
XSolarisOvlCopyPaintType – ソースドロアブルのペイント型属性に基づいて、宛先ドロアブルに不透明ポイントと透明ポイントを描画する。
-
XSolarisCopyAreaAndPaintType – ドロアブルの一方のペアから別のペアに領域とそのペイント型をコピーする。
-
XReadScreen – 指定された画面領域に表示されるカラーを戻す。
既存の Xlib ピクセル転送ルーチン XGetImage、XCopyArea、XCopyPlane も、オーバーレイウィンドウに使用できます。これらのルーチンの使用方法については、以下の節で説明します。
ソースエリアペイント型を使って描画する
XSolarisOvlCopyPaintType ルーチンは、ソース矩形内の指定された矩形のペイント型情報を使用して、宛先矩形内の指定された矩形の塗りつぶし操作を制御します。ソース矩形と宛先矩形には、任意のタイプのドロアブルを指定できます。ソース矩形が透明オーバーレイの場合は、そのピクセルのペイント型属性がコピーソースとして使用され、カラー情報は無視されます。ソース矩形が他のタイプのドロアブルであれば、ルーチン内で指定されたビットプレーンはペイント型データであるかのように処理され、コピーに使用されます。この場合、ビットプレーンはビットセットを 1 つだけ持たなければなりません。
構文と引数を次に示します。
void XSolarisOvlCopyPaintType(Display *display, Drawable src, Drawable dst, GC gc, int src_x, int src_y, unsigned int width, unsigned int height, int dest_x, int dest_y, unsigned long action, unsigned long plane)
|
display |
X サーバーへの接続を指定する。 |
|
src |
ペイント型属性に関する情報を取り出すソースのドロアブル (Drawable) を指定する。 |
|
dst |
宛先のドロアブルを指定する。 |
|
gc |
GCを指定する。 |
|
src_x, src_y |
ソース矩形の左上隅の xy 座標をソースドロアブルの原点に対する相対座標で指定する。 |
|
width, height |
ソースおよび宛先の矩形の幅と高さを指定する。 |
|
dest_x, dest_y |
宛先矩形の左上隅の xy 座標を宛先ドロアブルの原点に対する相対座標で指定する。 |
|
action |
コピーするペイント型データを指定する。指定できる値は、XSolarisOvlCopyOpaque、 XSolarisOvlCopyTransparent、または XSolarisOvlCopyAll のいずれか。 |
|
plane |
ソースが透明オーバーレイでないときにペイント型情報として使用する src ドロアブルのビットプレーンを指定する。 |
src と dst は同じスクリーンを持たなければなりません。そうしないと、BadMatch エラーが発生します。
表 6–4に、src と dst の組み合わせとその動作を示します。表の左側は src の組み合わせ、表の上側は dst の組み合わせを表します。A1〜A4 の各動作については、表に続いて説明します。
表 6–4 XSolarisOvlCopyPaintType のソース/宛先の組み合わせと動作|
ソース/宛先 |
オーバーレイ |
ドロアブル |
|---|---|---|
|
オーバーレイ |
A1 |
A2 |
|
ドロアブル |
A3 |
A4 |
-
A1 — ソースオーバーレイの不透明ピクセルに対応する宛先ピクセルは、GC の塗りつぶし属性で指定された不透明カラーで描画されます。ソースオーバーレイの透明ピクセルに対応する宛先ピクセルは、透明なペイントで描画されます。
-
A2 — ソースオーバーレイの不透明ピクセルに対応する宛先ピクセルは、GC の塗りつぶし属性に従って描画されます。ソースオーバーレイの透明ピクセルに対応する宛先ピクセルは、GC の同じ塗りつぶし属性に従って描画されますが、前景と背景のピクセルが交換されます。
-
A3 — 宛先オーバーレイのピクセルは、ソースドロアブルの plane のビット値に応じて (上記の A1 と同様に) 不透明ペイントまたは透明ペイントで描画されます。ソースの 1 というビット値は不透明ピクセルとして取り扱われ、0 というビット値は透明ピクセルとして取り扱われます。
-
A4 — 宛先ドロアブルのピクセルは、ソースドロアブルの plane のビット値に応じて (上記の A2 と同様に) 描画されます。ソースのビットプレーンの 1 というビット値は不透明ピクセルとして取り扱われ、0 というビット値は透明ピクセルとして取り扱われます。
action 引数は、不透明ペイント (XSolarisOvlCopyOpaque) 、透明ペイント (XSolarisOvlCopyTransparent) 、それら両方 (XSolarisOvlCopyAll) のいずれをコピー対象とするかを指定します。これによって、クライアントは不透明ペイントまたは透明ペイントを累積することができます。
ソース矩形の一部が、隠れたりソースドロアブルの境界外部にある場合、サーバーは XCopyArea と同じセマンティクスを使用して Expose イベントを生成します。
このルーチンで使用される GC 構成要素は、 function、 plane-mask、 fill-style、 subwindow-mode、 graphics-exposures、 clip-x-origin、 clip-y-origin、 clip-mask です。また、GC モードに依存する構成要素として、 foreground、 background、 tile、 stipple、 tile-stipple-x-origin、 tile-stipple-y-origin が使用される場合もあります。
このルーチンで発生する可能性のあるエラーは、 BadDrawable、 BadGC、 BadMatch、 BadValue です。
エリアとそのペイント型のコピー
XSolarisCopyAreaAndPaintType ルーチンは、カラー情報のソースとなるドロアブルの指定された領域を、カラー情報の宛先イメージとなるドロアブルの指定された領域にコピーします。宛先イメージとなるドロアブルがオーバーレイでなければ、ペイント型情報のソースとなるドロアブル内で指定されたペイント型情報に従って、ペイント型情報の宛先イメージとなるドロアブルの指定された領域も塗りつぶします。
XSolarisOvlCopyAreaAndPaintType ルーチンを使用すれば、カラーまたはペイント型の情報が格納されているクライアントのメモリー空間内のイメージと、指定されたオーバーレイウィンドウの矩形とを結合することができます。その場合は、最初にイメージとペイント型のデータをサーバーに移動し、XPutImage を使用して、適切なデプスの 2 つのピクセルマップにデータをコピーします。次に、カラーとペイント型のドロアブルを指定した XSolarisOvlCopyAreaAndPaintType を呼び出して、情報をオーバーレイにコピーします。
このルーチンを使用すれば、特定のドロアブルからピクセル情報 (カラーとペイント型の情報) を取り出すこともできます。その場合は、最初に 2 つの分離可能な宛先ドロアブルを指定する XSolarisOvlCopyAreaAndPaintType を呼び出します。次に、各ドロアブルに対して XGetImage を呼び出し、サーバーからクライアントのメモリー空間にデータを転送します。
XSolarisCopyAreaAndPaintType の構文と引数を次に示します。
void XSolarisOvlCopyAreaAndPaintType(Display * display, Drawable colorsrc, Drawable painttypesrc, Drawable colordst, Drawable painttypedst, GC colorgc, GC painttypegc, int colorsrc_x, int colorsrc_y, int painttypesrc_x, int painttypesrc_y, unsigned int width, unsigned int height, int colordst_x, int colordst_y, int painttypedst_x, int painttypedst_y, unsigned long action, unsigned long plane)
|
display |
X サーバーへの接続を指定する。 |
|
colorsrc |
カラー情報のソースとなるドロアブル。colorsrc として、任意のデプスのドロアブルまたはオーバーレイウィンドウを指定できる。 |
|
painttypesrc |
ペイント型情報のソースとなるドロアブル。painttypesrc として、任意のドロアブルまたはオーバーレイウィンドウを指定できる。painttypesrc がオーバーレイウィンドウでない場合、plane で指定された painttypesrc のビットプレーンはペイント型データであるかのように処理され、コピーに使用される。この場合、plane は 1 つのビットセットを持たなければならない。 |
|
colordst |
カラー情報の宛先となるドロアブル。 |
|
painttypedst |
ペイント型情報の宛先となるドロアブル。colordst がオーバーレイである場合、このドロアブルは無視される。 |
|
colorgc |
カラー情報のコピーに使用する GC。 |
|
painttypegc |
painttypedst 内の領域の描画に使用する GC。colordst/painttypedst がオーバーレイである場合、この GC は無視される。 |
|
colorsrc_x colorsrc_y |
カラー情報のソース矩形の左上隅の XY 座標を、カラー情報のソースドロアブルの原点に対する相対座標で指定する。 |
|
painttypesrc_x painttypesrc_y |
ペイント型情報のソース矩形の左上隅の XY 座標を、ペイント型情報のソースドロアブルの原点に対する相対座標で指定する。 |
|
width, height |
ソースおよび宛先の矩形の幅と高さをピクセル単位で指定する。 |
|
colordst_x colordst_y |
カラー情報の宛先矩形の左上隅の XY 座標を、カラー情報の宛先ドロアブルの原点に対する相対座標で指定する。 |
|
painttypedst_x painttypedst_y |
ペイント型情報の宛先矩形の左上隅の XY 座標を、ペイント型情報の宛先ドロアブルの原点に対する相対座標で指定する。colordst/painttypedst がオーバーレイである場合は、colordst_x と colordst_y が使用される。 |
|
action |
どのペイント型データをコピーするかを指定する。指定できる値は、XSolarisOvlCopyOpaque、 XSolarisOvlCopyTransparent、 XSolarisOvlCopyAll のいずれか。 |
|
plane |
painttypesrc がオーバーレイでないときに、ペイント型情報として使用する painttypesrc のソースビットプレーンを指定する。 |
colordst として任意のドロアブルを指定できますが、colorsrc と同じデプスで同じルートを持たないと、BadMatch エラーが発生します。colordst がオーバーレイの場合は、painttypedst が無視され、それ以外の場合は painttypedst として任意のタイプのドロアブルを指定できます。
表 6–5 に、ソースと宛先の組み合わせとそれらの動作を示します。表の左側は colorsrc/paittypesrc の組み合わせ、表の上側は colordst/painttypedst の組み合わせを表します。A1〜A8 の各動作については、表に続いて説明します。表の中で「不可能」と記載された箇所は、colordst がオーバーレイの場合は painttypedst が無視されるために、その組み合わせが不可能であることを示します。
表 6–5 XSolarisOvlCopyAreaAndPaintType のソース/宛先の組み合わせと動作|
|
オーバーレイ/オーバーレイ |
オーバーレイ/ドロアブル |
ドロアブル/オーバーレイ |
ドロアブル/ドロアブル |
|---|---|---|---|---|
|
オーバーレイ/オーバーレイ |
A1 |
不可能 |
A5 |
A5 |
|
オーバーレイ/ドロアブル |
A2 |
不可能 |
A6 |
A6 |
|
ドロアブル/オーバーレイ |
A3 |
不可能 |
A7 |
A7 |
|
ドロアブル/ドロアブル |
A4 |
不可能 |
A8 |
A8 |
-
A1 — painttypesrc のペイント型情報が、colorsrc から colordst にカラー情報をコピーするためのマスクとして使用されます。painttypesrc 内の不透明ピクセルに対応する colorsrc のピクセルは colordst にコピーされ、透明ピクセルに対応する colordst のピクセルは透明になります。colorsrc の透明ピクセルが colordst にコピーされる場合、実際に転送されるカラーは未定義になります。
-
A2 — plane で指定される painttypesrc のビットプレーンからペイント型情報が抽出される点以外は、A1 と同じです。1 というビット値は不透明ピクセルを表し、0 というビット値は透明ピクセルを表します。
-
A3 — オーバーレイでないドロアブルを使用してカラー情報が取得される点以外は、A1 と同じです。透明ピクセルを原因とする未定義のカラーは生じません。
-
A4 — A2 と同様に、 plane で指定される painttypesrc のビットプレーンからペイント型情報が抽出される点以外は、A3 と同じです。
-
A5 — A1 と同様に、 painttypesrc のペイント型情報が、colorsrc から colordst にカラー情報をコピーするためのマスクとして使用されます。さらに、XSolarisOvlCopyPaintType の場合のように、このペイント型情報によって painttypedst ドロアブルに対する描画が制御されます。
-
A6 — A2 と同様に、plane で指定される painttypesrc のビットプレーンからペイント型情報が抽出される点以外は、A5 と同じです。
-
A7 — カラー情報のソースの透明ピクセルを原因とする未定義のカラーが生じない点以外は、A5 と同じです。
-
A8 — A2 と同様に、 plane で指定される painttypesrc のビットプレーンからペイント型情報が抽出される点以外は、A7 と同じです。
action 引数は、不透明ペイント (XSolarisOvlCopyOpaque) 、透明ペイント (XSolarisOvlCopyTransparent) 、それら両方 (XSolarisOvlCopyAll) のいずれをコピー対象とするかを指定します。これによって、クライアントは不透明ペイントまたは透明ペイントを累積することができます。
XSolarisOvlCopyPaintType と同様の方法で、NoExpose イベントと GraphicsExpose イベントが生成されます。
colordst 引数にオーバーレイを指定すると、painttypedst、painttypegc、painttypedst_x、painttypedst_y の各引数はすべて無視されます。painttypegc には NULL ポインタ、painttypedst には None 値を指定できます。オーバーレイは、painttypesrc で指定される領域内のピクセルで定義されるのとまったく同じペイント型を持ちます。カラー情報をコピーしても、宛先のペイント型は影響を受けません。
このルーチンで使用される colorgc の GC 構成要素は、 function、 plane-mask、 subwindow-mode、 graphics-exposure、 clip-x-origin、 clip-y-origin、 clip-mask です。
colordst がオーバーレイでない場合は、 painttypegc の GC 構成要素として、 function、 plane-mask、 fill-style、 subwindow-mode、 clip-x-origin、 clip-y-origin、 clip-mask が使用されます。また、GC モードに依存する構成要素として、 foreground、 background、 tile、 stipple、 tile-stipple-x-origin、 tile-stipple-y-origin が使用される場合もあります。
このルーチンで発生する可能性のあるエラーは、 BadDrawable、 BadGC、 BadMatch、 BadValue です。
オーバーレイカラー情報の検索
XReadScreen は、スクリーンの矩形に表示されるカラーを戻します。このルーチンは、指定されたウィンドウの画面に表示されるカラーをアクセスします。
一部の高度な表示デバイス上では、表示されるカラーがデータの複合体として、複数の異なるフレーム記憶域に格納されており、これらのフレーム記憶域が異なるデプスやビジュアル型を持つことができます。また、アンダーレイの一部分がオーバーレイの下に見えるようなオーバーレイ/アンダーレイのウィンドウペアもあります。デプスが異なる矩形については、 XGetImage によって戻されるデータが未定義になるため、XGetImage は、ユーザーが実際に画面上で見ている画像を返すには不十分です。さらに、ピクセル情報が異なるドロアブルに存在するため、XGetImage はオーバーレイ/アンダーレイのウィンドウペアに関するピクセル情報を合成することができません。XReadScreen がこのような問題を解決します。
XReadScreen は、ピクセル情報ではなくカラー情報 (画面上に実際に表示される可視カラー) を戻します。すなわち、指定された矩形の境界内部のすべてのウィンドウに関するカラー情報を戻します。XGetImage とは違って、指定されたウィンドウのデプスとは異なるデプスを持つ下層ウィンドウやオーバラップウィンドウであっても、その可視領域について戻される情報は未定義にはならず、これらのウィンドウで実際に表示されるカラーが戻されます。
注 –
戻されるカラーは、画面上で利用できるハードウェアカラー LUT の数に制限がないと想定した場合には、表示されるカラーとなります。したがって、このカラーは理論的な表示カラーを意味します。すべてのソフトウェアカラーマップを同時に表示するのに十分な数のハードウェアカラー LUT がないと、画面上でカラーマップフラッシングが発生しますが、この場合は、戻されるカラーと実際に表示されるカラーが一致しないことがあります。
このルーチンの構文と引数を次に示します。
XImage
* XReadScreen (Display *display, Window w, int x, int y,
unsigned int width, unsigned int height,
Bool includeCursor)
|
display |
X サーバーへの接続を指定する。 |
|
w |
スクリーンのデータが読み取られるウィンドウを指定する。 |
|
x, y |
矩形の左上隅の XY 座標をウィンドウ w の原点に対する相対座標で指定する。 |
|
width, height |
矩形の幅と高さを指定する。 |
|
includeCursor |
戻されるカラーにカーソルイメージを含めるかどうかを指定する。 |
w がオーバーレイウィンドウである場合、指定された矩形内に不透明なペイントが存在するすべての領域については、オーバーレイのカラー情報が戻されます。オーバーレイ内に透明なペイントが存在する領域については、アンダーレイのカラー情報が戻されます。通常、このアンダーレイは透明ペイントを含むオーバーレイウィンドウにできるため、透明ペイントを含む (x, y) 座標に関するカラー情報は、(x, y) に不透明なペイントを持つ最初に出合った上層ウインドウを表します。
カラー情報は、XImage として戻されます。戻されるイメージの幅と高さは、引数で指定された値と同じになります。イメージの形式は ZPixmap です。イメージのデプスは 24、bits_per_pixel は 32 です。各カラーチャネル (赤、緑、青) に関するカラー情報の最上位 8 ビットは、XImage 内の red_mask、green_mask、blue_mask で定義されるビット位置に戻されます。XImage の属性値のうちサーバーに依存するものは、byte_order, bitmap_unit, bitmap_bit_order, bitmap_pad, bytes_per_line, red_mask, green_mask, blue_mask です。
includeCursor が True の場合は、戻されるカラーにカーソルイメージが含められ、それ以外の場合は、除外されます。
このルーチンでは、引数のウィンドウ (およびその他のウィンドウ) の境界も読み取られることに注意してください。
問題が発生すると、XReadScreen は NULL を戻します。
既存の Xlib ピクセル転送ルーチンを使用する
Xlib ピクセル転送ルーチン XGetImage、XCopyArea、XCopyPlane も、透明オーバーレイウィンドウに使用できます。
XGetImage
オーバーレイ以外のドロアブル上では、XGetImage ルーチンは X11 仕様で定義されたとおりに動作します。オーバーレイウィンドウについても同じことが言えますが、例外として、これらのウィンドウ上では透明なピクセルについて戻されるカラー情報は未定義になります。画面上の領域の表示カラーを検索するだけの場合は、XReadScreen を使用してください。
XCopyArea および XCopyPlane
ソースと宛先のドロアブルが両方ともオーバーレイ以外の場合、これらのルーチンは X11 仕様で定義されたとおりに動作します。ただし、ソースまたは宛先となるドロアブルがオーバーレイウィンドウの場合は、次の点に注意してください。
-
ソースのドロアブルがオーバーレイで、宛先のドロアブルがオーバーレイ以外の場合は、カラー情報だけがコピーされ、ソースのペイント型情報は無視されます。透明なピクセルに関するカラー情報は未定義になります。
-
ソースのドロアブルがオーバーレイ以外で、宛先のドロアブルがオーバーレイである場合は、GC のペイント型で指定されたとおりにコピーが実行されます。すなわち、ペイント型が XSolarisOvlPaintOpaque の場合は、不透明なペイントを使用してカラー情報が宛先にコピーされます。ペイント型が XSolarisOvlPaintTransparent の場合は、カラー情報が無視され、宛先のピクセルは透明になります。
-
ソースと宛先のドロアブルが両方ともオーバーレイの場合は、ソースのペイント型が無視され、ソースがオーバーレイでない場合と同じ動作になります。カラーとペイント型の両方の情報をコピーしたい場合は、XSolarisOvlCopyAreaAndPaintType を使用してください。
アプリケーションの移植性の設計
Solaris オーバーレイ API には、デバイス間でアプリケーションの移植性を保証できるように、次の 2 つのルーチンが用意されています。
-
XSolarisOvlSelectPartner – アプリケーションで既存のオーバーレイビジュアルまたはアンダーレイビジュアルに最適の組み合わせになるビジュアルを選択できるようにする。
-
XSolarisOvlSelectPair – アプリケーションで、画面用のすべてのビジュアルペアセットから最適のオーバーレイビジュアルとアンダーレイビジュアルのペアを選択できるようにする。
次に、この 2 つのルーチンについて説明します。
オーバーレイ/アンダーレイウィンドウのビジュアルの選択
オーバーレイを使用するアプリケーションの移植性を維持するためには、適切なオーバーレイビジュアルを探索し、指定されたアンダーレイビジュアルに使用できることが必要です。あるいは適切なアンダーレイビジュアルを探索し、指定されたオーバーレイビジュアルに使用できることが必要です。オーバーレイ拡張機能をサポートする各 X スクリーンでは、アンダーレイウィンドウの子として使用するのに最適なウィンドウを持つオーバーレイビジュアルの集合が定義されます。各アンダーレイビジュアルごとに最適なオーバーレイビジュアルの集合が存在します。アンダーレイビジュアルとそれらに最適なオーバーレイビジュアルの組み合わせによって、各スクリーンの「オーバーレイ/アンダーレイの最適なペア」が形成されます。最適なペアを形成するオーバーレイ/アンダーレイの各ビジュアルは、お互いの「パートナ」と呼ばれます。
ルーチン XSolarisOvlSelectPartner を使用すれば、アンダーレイビジュアルを入力として与えて、特定の条件を満たす最適なオーバーレイビジュアルを選択することができます。またその逆に、オーバーレイビジュアルを入力として与えて、特定の条件を満たす最適なアンダーレイビジュアルを選択することもできます。オーバーレイに関係のない X エラーは別として、選択されたビジュアルを使用すれば、ウィンドウを安全に作成することができます。
このルーチンは、特定のビジュアルの最適なパートナを探索し、条件に合致するビジュアルが見つかったかどうかに応じて成功または失敗を表す状態を戻します。条件には次の 2 つの種類があります。
-
ハード条件 – 必ず満たされなければならない条件。ハード条件を満たすビジュアルだけが最適なペアの候補となります。
-
ソフト条件 – 必須ではないが満たされたほうが望ましい条件。
すべてのハード条件と大部分のソフト条件を満たすビジュアルが選択され、そのビジュアルの属性が戻されます。すべてのハード条件および同じ数のソフト条件を満たすビジュアルが複数見つかった場合は、そのうち 1 つのビジュアルが選択されて戻されます。どのビジュアルが選択されるかは、実装状態によって異なります。
XSolarisOvlSelectPartner の構文と引数を次に示します。
XSolarisOvlSelectStatus XSolarisOvlSelectPartner (Display *display, int screen, VisualID vid, XSolarisOvlSelectType seltype, int numCriteria, XSolarisOvlVisualCriteria *pCriteria, XVisualInfo *visinfoReturn, unsigned long *unmetCriteriaReturn)
|
display |
X サーバーへの接続を指定する。 |
|
screen |
ビジュアル vid のスクリーンを指定する整数。 |
|
vid |
パートナを探すビジュアルの XID。 |
|
seltype |
選択対象となるビジュアルの種類を指定する。 |
|
numCriteria |
pCriteria 配列の中にあるXSolarisOvlVisualCriteria 構造体の数。 |
|
pCriteria |
ビジュアルを選択するための条件を優先順位の高い順に指定した XSolarisOvlVisualCriteria 構造体の配列。 |
|
visinfoReturn |
呼び出し側が提供する XVisualInfo 構造体へのポインタ。正常終了の場合は、選択されたビジュアルの属性がこの構造体に書き込まれる。 |
|
unmetCriteriaReturn |
満足されなかった条件を記述するビットマスクへのポインタ。この出力引数が意味を持つのは、ルーチンが XSolarisOvlQualifiedSuccessまたは XSolarisOvlCriteriaFailure という値を戻すときに限られる。 |
引数の型
XSolarisOvlSelectType は、XSolarisOvlSelectPartner 内で選択できる 2 種類のビジュアルを定義する列挙型です。この構造体は、次のように定義されます。
typedef
enum { XSolarisOvlSelectBestOverlay, XSolarisOvlSelectBestUnderlay, }
XSolarisOvlSelectType;
XSolarisOvlVisualCriteria はビジュアルの選択時に使用される各種条件と、それらの条件の重要度を定義する構造体です。この構造体は次のように定義されます。
typedef
struct { unsigned long hardCriteriaMask; unsigned
long softCriteriaMask int c_class; unsigned int depth; unsigned
int minColors; unsigned int minRed; unsigned int minGreen;
unsigned int minBlue; unsigned int minBitsPerRGB;
unsigned int minBuffers; }
XSolarisOvlVisualCriteria;
hardCriteriaMask と softCriteriaMask は、次に示す任意のビットマスクの論理和を値とするビットマスクです。
#define XSolarisOvlVisualClass (1L<<0) #define XSolarisOvlDepth (1L<<1) #define XSolarisOvl MinColors (1L<<2) #define XSolarisOvlMinRed (1L<<3) #define XSolarisOvl MinGreen (1L<<4) #define XSolarisOvl MinBlue (1L<<5) #define XSolarisOvlMinBitsPerRGB (1L<<6) #define XSolarisOvl MinBuffers (1L<<7) #define XSolarisOvlUnsharedPixels (1L<<8) #define XSolarisOvlUnsharedColors (1L<<9) #define XSolarisOvlPreferredPartner (1L<<10)
戻り値の型
XSolarisOvlSelectStatus はルーチンがビジュアルの探索に成功したかどうか、失敗した場合はその理由を示す値です。戻り値は、次のいずれかになります。
typedef
enum { XSolarisOvlSuccess, XSolarisOvlQualifiedSuccess,
XSolarisOvlCriteriaFailure, XSolarisOvlFailure, }
XSolarisOvlSelectStatus;
-
1 つの XSolarisOvlVisualCriteria 構造体で指定された、すべてのハード条件とソフト条件を満たすビジュアルが正常に見つかった場合は、XSolarisOvlSuccess が戻されます。
-
選択されたビジュアルが、1 つの XSolarisOvlVisualCriteria 構造体で指定された、すべてのハード条件は満たすが、ソフト条件は満たさない場合は、XSolarisOvlQualifiedSuccess が戻されます。この場合は、満たされなかったソフト条件の論理和が unmetCriteriaReturn に書き込まれます。
-
XSolarisOvlCriteriaFailure は、XSolarisOvlVisualCriteria 構造体で指定されたハード条件を満たすビジュアルが見つからなかったことを示します。この場合は、もっとも緩いハード条件を持つ XSolarisOvlVisualCriteria 構造体について、満たされなかったハード条件の論理和が unmetCriteriaReturn に書き込まれます。
-
条件の不一致以外のエラーが発生した場合は、XSolarisOvlFailure が戻されます。
複数の条件集合
このルーチンでは、優先順位の高い順に条件集合を指定することができます。すなわち、単一の呼び出しで複数の条件集合が指定できます。まず、最初の条件集合に合致するビジュアルの探索がルーチンにより行われ、最初の条件集合のすべてのハード条件を満たすビジュアルが見つかると、そのビジュアルが選択されます。そのようなビジュアルが見つからない場合は、2 番目の条件集合を使用して探索が続けられます。このような手続きは、特定の条件集合のすべてのハード条件を満たすビジュアルが見つかるか、すべての条件集合のテストが終了するまで続けられます。すなわち、この優先順位の仕組みでは、もっとも望ましいビジュアルを最初の条件集合として指定し、それより優先度の低いビジュアルについては 2 番目以降の条件集合として指定すればよいわけです。この仕組みにより、単一のサブルーチン呼び出しで、ビジュアルに関するユーザーの要求を優先順位の高い順に探索することができます。
特定の条件集合では、任意の条件をハード条件またはソフト条件として指定することができます。特定の条件の hardCriteriaMask は、探索時にハード条件として指定する条件ビットマスクの論理和です。同様に、softCriteriaMask はソフト条件ビットマスクの論理和です。
条件の中には特定の値を取るものがあります。これらの値は、XSolarisOvlVisualCriteria 構造体の他のデータメンバによって提供されます。以下の条件の説明では、これらのデータメンバを必要に応じて取り上げます。
-
XSolarisOvlVisualClass は、選択されたビジュアルが特定のビジュアルクラスを持つことを指定します。そのビジュアルクラスは c_class で指定します。
-
XSolarisOvlDepth, XSolarisOvlMinColors, XSolarisOvlMinRed, XSolarisOvlMinGreen, XSolarisOvlMinBlue の各条件は、相互に関連があります。通常は、これらの条件の一部だけを指定します。
-
XSolarisOvlDepth は、選択されたビジュアルのデプスが depth に等しくなることを指定します。
-
XSolarisOvlMinColors は、選択されたビジュアルで表示可能なカラーの総数が少なくとも minColors 個であることを指定します。
-
XSolarisOvlMinRed、XSolarisOvlMinGreen、XSolarisOvlMinBlue を使用すれば、DirectColor ビジュアルまたは TrueColor ビジュアルについて詳細なカラー条件を指定することができます。各条件に対応する値はそれぞれ、minRed、minGreen、minBlue で指定します。これらのデータメンバの値は、選択されたビジュアルの赤、緑、青の要素値の下限を指定するものです。
-
XSolarisOvlMinBitsPerRGB は、選択されたビジュアル上で作成されるカラーマップからのカラーチャネル出力が少なくとも minBitsPerRGB であることを指定します。
-
XSolarisOvlMinBuffers は、選択されたビジュアルに少なくとも minBuffers 個の高速 MBX イメージバッファを割り当てることを指定します。
-
XSolarisOvlUnsharedPixels は、引数のビジュアル vid のウィンドウピクセルとは異なる描画プレーングループ内に存在するウィンドウピクセルを持つパートナビジュアルを選択します。この条件下では、引数のビジュアルと同じ描画プレーングループを使用するビジュアルは選択されません。
-
XSolarisOvlUnsharedColors は、オーバーレイ/アンダーレイのウィンドウペアがカラーマップのフォーカスを保持しているときに、ウィンドウピクセルのカラーを同時に表示できるようなパートナビジュアルを選択します。この条件下では、ビジュアルが単一のカラー LUT プールを共有し、そのプール内に引数のビジュアルと同じカラー LUT が 1 個しか存在しない場合、そのビジュアルは選択されません。
条件集合の hardCriteriaMask をゼロに設定すると、任意のビジュアルがその条件集合のハード条件を満たすことになります。同様に、条件集合の softCriteriaMask をゼロに設定すると、その条件集合のソフト条件は必ず満たされることになります。
オーバーレイ/アンダーレイビジュアルの最適なペアの選択
このルーチンは XSolarisOvlSelectPartner と似ていますが、特定のビジュアルのパートナビジュアルを見つけるのではなく、特定のスクリーン上のすべてのビジュアルペアから、指定された条件にもっとも合致するオーバーレイとアンダーレイのペアを同時に選択します。オーバーレイに関係のない X エラーは別として、選択されたビジュアルを使用すれば、ウィンドウを安全に作成することができます。
このルーチンは、pCriteria で指定された条件に基づいて、特定のスクリーンの最適なビジュアルペアを探索し、それからすべてのビジュアルペア (最適なペアとそれ以外のペア) を探索します。オーバーレイとアンダーレイに関する条件は、pCriteria の各要素で指定されます。このルーチンは、指定された条件に合致するペアが見つかったかどうかに応じて成功または失敗を表す状態を戻します。
選択されたペアのオーバーレイビジュアルは、オーバーレイに関するすべてのハード条件を満たします。また、このペアのアンダーレイビジュアルは、アンダーレイに関するすべてのハード条件を満たします。オーバーレイビジュアルの属性は ovVisinfoReturn に戻され、アンダーレイビジュアルの属性は unVisinfoReturn に戻されます。すべてのハード条件 (オーバーレイとアンダーレイ) および同じ数のソフト条件 (オーバーレイまたはアンダーレイ) を満たすビジュアルペアが複数見つかった場合は、そのうち 1 つのペアが選択されて戻されます。どのペアが選択されるかは、実装状態によって異なります。
構文と引数を次に示します。
XSolarisOvlSelectStatus XSolarisOvlSelectPair (Display *display, int screen, int numCriteria, XSolarisOvlPairCriteria *pCriteria, XVisualInfo *ovVisinfoReturn, XVisualInfo *unVisinfoReturn, unsigned long *unmetOvCriteriaReturn, unsigned long *unmetUnCriteriaReturn)
|
display |
X サーバーへの接続を指定する。 |
|
screen |
ビジュアルの探索場所となるスクリーンを指定する整数。 |
|
numCriteria |
pCriteria 配列の中にある XSolarisOvlPairCriteria 構造体の数。 |
|
pCriteria |
ビジュアルのペアを選択するための条件を優先順位の高い順から低い順に指定した XSolarisOvlPairCriteria 構造体の配列。 |
|
ovVisinfoReturn |
呼び出し側が提供する XVisualInfo 構造体へのポインタ。正常終了の場合は、選択されたオーバーレイビジュアルの属性がこの構造体に書き込まれる。 |
|
unVisinfoReturn |
呼び出し側が提供する XVisualInfo 構造体へのポインタ。正常終了の場合は、選択されたアンダーレイビジュアルの属性がこの構造体に書き込まれる。 |
|
unmetOvCriteriaReturn |
オーバーレイビジュアルに関して満足されなかった条件を記述するビットマスクへのポインタ。この出力引数が意味を持つのは、ルーチンが XSolarisOvlQualifiedSuccess または XSolarisOvlCriteriaFailure という値を戻すときに限られる。 |
|
unmetUnCriteriaReturn |
アンダーレイビジュアルに関して満足されなかった条件を記述するビットマスクへのポインタ。この出力引数が意味を持つのは、ルーチンが XSolarisOvlQualifiedSuccess または XSolarisOvlCriteriaFailure という値を戻すときに限られる。 |
引数の型
XSolarisOvlPairCriteria はビジュアルの選択時に使用される各種条件と、それらの条件の重要度を定義する構造体です。この構造体は次のように定義されます。
typedef
struct { XSolarisOvlVisualCriteria overlayCriteria;
XSolarisOvlVisualCriteria underlayCriteria; }
XSolarisOvlPairCriteria;
XSolarisOvlVisualCriteria は、XSolarisOvlSelectPartner の仕様で定義されています。
戻り値の型
XSolarisOvlSelectStatus はこの型の定義については、XSolarisOvlSelectPartner の仕様を参照してください。
-
XSolarisOvlPairCriteria 構造体の 1 つで指定されたすべてのハード条件とソフト条件を満たすビジュアルペアが正常に見つかった場合は、XSolarisOvlSuccess が戻されます。
-
選択されたビジュアルが XSolarisOvlPairCriteria 構造体の 1 つで指定されたすべてのハード条件を満たすが、ソフト条件は満たさない場合は、XSolarisOvlQualifiedSuccess が戻されます。この場合は、オーバーレイとアンダーレイに関して満たされなかったソフト条件の論理和が、それぞれ unmetOvCriteriaReturn と unmetUnCriteriaReturn に書き込まれます。
-
XSolarisOvlCriteriaFailure は、XSolarisOvlPairCriteria 構造体で指定されたハード条件を満たすビジュアルペアが見つからなかったことを示します。この場合は、オーバーレイとアンダーレイに関し、XSolarisOvlPairCriteria 構造体の満たされなかったハード条件のうち、もっとも緩いハード条件の 論理和が、それぞれ unmetOvCriteriaReturn と unmetUnCriteriaReturn に書き込まれます。
-
条件の不一致以外のエラーが発生した場合は、XSolarisOvlFailure が戻されます。
条件集合
XSolarisOvlSelectPartner と同様に、XSolarisOvlSelectPair では、優先順位の高い順に条件集合を指定することができます。すなわち、単一の呼び出しで複数の条件集合が指定できます。まず、オーバーレイとアンダーレイに関する最初の条件集合に合致するビジュアルペアの探索がルーチンにより行われ、最初の条件集合のすべてのハード条件を満たすペアが見つかると、そのペアが選択されます。そのようなペアが見つからない場合は、2 番目の条件集合を使用して探索が続けられます。このような手続きは、特定の条件集合のすべてのハード条件を満たすペアが見つかるか、すべての条件集合がテストされるまで続けられます。すなわち、この優先順位の仕組みでは、もっとも望ましいペアを最初の条件集合として指定し、それより優先度の低いペアについては 2 番目以降の条件集合として指定すればよいわけです。この仕組みにより、単一のサブルーチン呼び出しで、ペアに関するユーザーの要求を優先順位の高い順に探索することができます。
指定できる条件マスクの詳細については、オーバーレイ/アンダーレイウィンドウのビジュアルの選択を参照してください。
- © 2010, Oracle Corporation and/or its affiliates