Palm OS Programmer’s Companion Volume I/4-2 - project-enigma

Palm OS Programmer’s Companion Volume I/4-2

>> Site top >> Misc >> In my palm >> Palm開発ドキュメントの和訳 >> Palm OS Programmer’s Companion Volume I >> Palm OS Programmer’s Companion Volume I/4-2

最終更新日付:2014/01/01 00:00:00

← 1 節に戻る ↑4 章トップへ 3 節に進む →

4-2 Palmハンドヘルドにおける描画

 

初期の Palm ハンドヘルドは 160x160 ピクセルの LCD スクリーンを有していました。以降、320x320 や 320x240 ピクセルのものが発表されています。組込みの LCD コントローラはシステムメモリの一部を LCD にマップします。コントローラの能力はハンドヘルドによって異なりますが、ハードウェアによっては実際に表示可能な深度が制限される場合もあることに注意してください。表 4.2 に Palm OS がサポートするビット深度を一覧します。

表 4.2 サポートされるビット深度

Palm OS Version Supported Resolutions
1.0 1 bit/pixel
2.0 1 bit/pixel
3.0 1 or 2 bits/pixel
3.3 1,2,or 4 bits/pixel
3.5 1,2,4 or 8 bits/pixel
4.x,5.x 1,2,4,8,or 16 bits/pixel
  (詳細は「4-15 カラーとグレイスケールのサポート」を参照

通常、特定のイベントを受信すると、フォームマネージャがスクリーンへの全ての必要な描画と再描画を処理します(Palm OS では、フォームはデスクトップアプリケーションでいうウィンドウの意味で、ウィンドウは論理的な描画領域を意味します)。描画ルーチンを明示的にコールする必要はありません。ただし、アニメーションをしたり、(ガジェットのような)カスタムUIオブジェクトを使うのであれば、ウィンドウマネージャが提供する描画関数を使う必要があるかもしれません。

ウィンドウマネージャはウィンドウオブジェクトを定義し、ウィンドウを描画する関数を提供します。ウィンドウは画面上またはオフスクリーンの描画領域です。ウィンドウのデータ構造体はウィンドウに実際に表示されるデータを含むビットマップを保有しています。ウィンドウはビットマップ上のクリッピング領域と言い換えることもできます。

 

描画ステート

ウィンドウマネージャは描画ステート ── ペンの色、パターン、グラフィックの状態など ──も定義します。描画ステートはオペレーティングシステムのバージョンによって異なった処理が行なわれます。

バージョン 3.5 未満の Palm OS では、システムは描画ステートの各要素に対応するいくつかのグローバル変数を個別に管理していました。描画ステートを変更したければ、WinSet〜 関数(例えば WinSetUnderlineMode 関数)を使用します。各 WinSet〜 関数は設定以前の古い値を返します。この返される値は保存しておき、必要な描画が終わったら再び関数をコールして元の値を再設定しなければなりません。システムの描画ステートをトラックするためにアプリケーションのスタック領域を使うという意味で、このやり方は不便と言えます。さらに、もし呼び出し元が値の復元を忘れてしまうと、ハンドヘルド全体のルック&フィールが変わってしまう可能性があります。

Palm OS 3.5 以降では、描画ステートを簡単にトラックするために、2つの点で改善が行なわれました。1つ目は、描画関連のグローバル変数群をグループにし、1つのユニットとして扱うようになったことです。この描画ステートは Palm OSにおけるペンの実装です。これにはその時点での移動(と描画)モード、WinFill〜系関数のためのパターンモードとパターンデータ、および前景色と背景色が含まれています。また、テキストに関連する描画情報も含まれています。フォント ID、アンダーラインのモード、およびテキストカラーです(Palm OS は現在ペン幅、ペンの形状、コーナー形状など、その他のペンライクなコンセプトをサポートしていません)。システムには1つの描画ステートだけが存在します。

2つ目は、Palm OS 3.5 では描画ステートの変更をスタックに保存することでトラックできるようになったことです。アプリケーションはもう描画ステートのデータのためにスタック領域を使う必要はありません。そのかわり、WinPushDrawState 関数を使って現在の描画ステートのコピーをスタックの先頭にプッシュします。次に既存の WinSet〜系関数を使って描画ステートを変更します。描画が完了して描画ステートをレストアしたくなったら、 WinPopDrawState 関数をコールします。

この新しい描画ステートスタックは、デバッグの手助けもしてくれます。スタックを十分にポップせずに、あるいはポップしすぎでアプリケーションが終了した場合、デバッグROM ではこれが検出されて警告が表示されます。アプリケーション切り替えの際には、システムはアプリケーション終了時点でデフォルトのステートまでポップし、次のアプリケーションが起動する際にシステム固有の描画ステートになっていることを保証します。

 

描画関数

ウィンドウマネージャは矩形、線、文字、ビットマップ、および ( バージョン 3.5 以降では )ピクセルを描画できます。ウィンドウマネージャのほとんどの関数は表 4.3 に示す5つのバリエーションに分類されます。

表 4.3 ウィンドウマネージャの描画関数

モード オペレーション
Draw 前景色とパターンを使用してオブジェクトの輪郭だけを描画します。ビットマップにおいては、ビットマップ全体を描画します。
Fill 前景色とパターンを使用して、オブジェクトの内側だけを描画します。
Erase ウィンドウの背景色を使用して、オブジェクトの輪郭と内側を消去します。
Invert オブジェクトの領域内部の前景色と背景色を入れ替えます。
Paint バージョン 3.5 以降のみでサポートされます。描画ステートの全て ── 移動モード、前景色・背景色、パターン、フォント、文字色、および下線モード ── を使用してオブジェクトを描画します。

描画関数は常にカレント描画ウィンドウに描画します。これは実際の画面上のウィンドウかもしれませんし、オフスクリーンウィンドウかもしれません。これらの関数をコールする前に、WinSetDrawWindow を使用して描画ウィンドウを設定します。

 

高密度( High-Density )ディスプレイ

ほとんどの Palm ハンドヘルドの画面は 160 ピクセルの幅と 160 ピクセルの高さになっています。高密度( High-Density )ディスプレイフィーチャセットよりも前の時点では、オペレーティングシステムは他のスクリーンサイズはほとんどサポートしていませんでした。高密度ディスプレイフィーチャセットは 320 x 320、つまり倍密度のディスプレイをサポートし、1.5x ディスプレイフィーチャセットは 320 x 240 (脚注1)、つまり 1.5 倍の高密度ディスプレイをサポートします。このサポートは、倍密度スクリーンの Palm ハンドヘルドでも単密度スクリーン( 160 x 160 )向けにデザインされたアプリケーションを変更なしで動作させられるようにデザインされています。

脚注1

320 x 240 は"QVGA"(quarter VGA) として知られています。ディスプレイの一部は入力エリアとして確保されています。QVGA スクリーンの描画エリアは 240 x 240 ピクセルです。この解像度は 1.5 倍密度と呼ばれることがあります。

 

画面密度

画面の密度はスクリーンの幅と高さと標準的な 160 x 160 ピクセルスクリーンの幅・高さとのピクセル数における比率を意味しています。スクリーンの密度はスクリーンの物理的なサイズとは何の関係もありません。一般的なPalmハンドヘルドのフォームファクタにおいては、スクリーンはディスプレイの密度を別にすれば概ね同じサイズになります。

※訳注

フォームファクタ( form factor )の適切な訳ができませんでした。ひとまず逃げ腰な訳にしています。

倍密度スクリーンは、単密度スクリーンと比べて同じサイズで各方向に2倍のピクセル数が収まります。スクリーンの密度に関係なく、グラフィック要素はスクリーン領域の同じ位置に同じ割合で表示されます。例えばアドレス帳アプリケーションでは、単密度か倍密度かに関わらずスクリーン上には11行のテキストが表示されます。テキストは倍密度スクリーンの方がより綺麗に見えますが、これは描画エンジン(blitter)がテキストを描画する際、各文字がより多くのピクセルで構成されている倍密度用フォントを使用しているからです。

※訳注

blitter は一般的な辞書には載っていませんが、The Jargon File によれば「blit オペレーションのための専用チップ」で、blit は「大きなビット列をメモリのある場所から別の場所にコピーすること」だそうです。しかし、このセクションのもう少し下には別の説明がなされています。その説明に従い、ここでは「描画エンジン」と表現しています。

NOTE

高密度ディスプレイフィーチャセットは様々な密度のスクリーンサイズをサポートするようにデザインされています。ただし、Palm OS Garnet の描画エンジン(blitter)は単密度、1.5倍密度、および倍密度のディスプレイだけをサポートします。

Palm OS ハンドヘルドのアプリケーションを作成する場合、通常はピクセルの文脈で考えるのをやめ、スクリーン座標で考えるようにします。オペレーティングシステムが座標と物理的なピクセルのマッピングを考慮してくれますし、描画関数は座標の文脈で動作してくれます。例えば、組込みフォントの1つを使ってテキスト文字列を描画するとします。このフォントは標準座標で 12 の高さになっています。ディスプレイの密度によって、このテキストは 12 ピクセルの高さになるかもしれませんし、24 ピクセルの高さ( 倍密度ディスプレイの場合 )に、あるいは他の 12 の倍数になるかもしれません。

 

用語

以下の用語を明確に理解しておくことは、高密度ディスプレイフィーチャセットの概念を理解する上でとても重要です。

デフォルト密度

標準座標あたり1ピクセルのレイアウト。

高密度

低密度のレイアウトよりも標準座標あたりのピクセル数が多いレイアウト。

低密度

デフォルト密度と同義。すなわち、標準座標あたり1ピクセル。

ネイティブ座標系

描画ウィンドウの密度を基準にした座標系。スクリーンに描画を行う場合、これは物理的なスクリーンピクセルの密度と一致します。オフスクリーンウィンドウでは、ネイティブ座標は物理的なスクリーンではなくオフスクリーンビットマップの密度が基準となります。

標準座標系

高密度ディスプレイフィーチャセットがインストールされていない多くのハンドヘルドで使われている座標系。単密度スクリーンでは、標準座標1単位がスクリーンの1ピクセルにあたります。高密度スクリーンでは、標準座標1単位はそれ以上のピクセル数となります。

 

実装

Palm OS 上で動作するアプリケーションは、ハンドヘルドが高密度スクリーンを有している場合でも、デフォルトでは標準座標系で動作します。フォームを作成する際には、これまでどおり標準座標系を用いてフォームの寸法や UI 要素の位置を指定します。

Palm OS では、全ての描画処理に描画ステートが使用されます。高密度ディスプレイフィーチャセットによってこの描画ステートにスケーリングファクタが追加されます。これは描画関数( WinDrawLine、WinCopyRectangle、WinPaintPixel など )に渡される座標関連の引数をネイティブ座標系に変換するためにウィンドウマネージャによって使用されるもので、アクティブな座標系からネイティブ座標系への変換比率を指しています。

描画処理はウィンドウマネージャの関数が行ないます。これは描画ステートを初期化してから描画エンジン(blitter)をコールします。blitter とは、スクリーン上の適切な位置に線や矩形、グラフィック要素などを描画する低水準のコードです。ウィンドウマネージャは描画関数に渡された座標引数をウィンドウの座標系から、描画エンジンが使用するネイティブ座標系に変換します。描画エンジンは整数値の座標を要求するため、ほとんどの WinScale〜 および WinUnscale〜 系関数には結果の整数値を切り捨てるか丸めるかを指示するパラメータがあります(脚注2)。WinScaleRectangle と WinUnscaleRectangle はこのルールの例外で、拡縮の結果、長さや座標位置に端数が出た場合、計算結果は常に繰り上げられます。

 

脚注2

Palm OS Cobalt では、このアルゴリズムは少し異なっています。座標のスケーリングファクタが適用された後、以下のアルゴリズムが適用されます。

if ceiling == true {
    use lfloorf() function when scaleFactor > 1
    use lceilf() function when scaleFactor < 1
else
    use lceilf() function when scaleFactor > 1
    use lfloorf() function when scaleFactor < 1
}

 

このアルゴリズムの目的は、Coord、Point、Rectangle などであるような全ての "x" に対して、x = unscaled(scaled(x)) が成立するよう保証することです。

 

WinSetCoordinateSystem 関数を使用することで、アプリケーションは描画関数が使用する座標系を指定することができます。高密度スクリーンを備えたハンドヘルドにおいては、このことはアプリケーションが標準座標系かネイティブ座標系のいずれかを使用できることを意味します。ただし、WindowType 構造体の bounds および clippingBounds フィールドは常にネイティブ座標で設定されることに注意して下さい。これらのフィールドにアクセスする各種の関数は、ネイティブ座標からウィンドウが使用している座標系への変換を行います。

ウィンドウが使用している座標系がどれかによって、グラフィック要素の位置と寸法に影響が出ます。ただし、ビットマップには影響しません。ビットマップは、低密度と高密度のいずれかのビットマップデータを有するものを作成できます。ビットマップの密度はBitmapTypeV3 データ構造体に記録されています。描画エンジン(blitter)が描画にあたってビットマップの拡縮が必要かどうかを判断するのにビットマップ構造体の density フィールドを使用するのに対して、ウィンドウマネージャはビットマップの左上隅をスクリーン上のどこに配置するかを決めるためにウィンドウの座標系を使用します。

例として、倍密度スクリーンを持つ Palm ハンドヘルド上のアプリケーションで幅 30ピクセル、高さ 70 ピクセルの低密度ビットマップを描画することを考えます。表示座標系を使って、アプリケーションはウィンドウマネージャに対してウィンドウ座標( 10, 20 )に描画するよう指示します。ウィンドウマネージャは座標( 10, 20 )をネイティブ座標系に変換し、描画エンジンに対してネイティブ座標( 20, 40 )に描画するように指示します。描画エンジンはそれが低密度ビットマップであることを認識すると、各ピクセルを2倍にして描画します。結果として、倍密度スクリーンでは幅 60、高さ 140 でビットマップが表示されます。

グラフィック要素の位置と寸法に使用される座標系がなんであろうと、高密度フォントを利用するのに新しい関数は必要ありません。高密度フォントは高密度ウィンドウでのテキスト描画においてデフォルトで使用されます。

NOTE

フォントとビットマップの拡縮は最新バージョンの Palm OS で動作する高密度スクリーンのハンドヘルドでは無効にすることができます。これにより、アプリケーションはより大きなグラフィックを表示し、一度により多くのテキストを表示することができます。詳細は、「Palm OS Programmer’s API Reference」の WinSetScalingMode のページを参照して下さい。

1.5 倍密度のディスプレイの場合、拡縮の挙動はアプリケーションをどのように作成したかによって変わります。ウィンドウマネージャは表座標系からネイティブ座標系の変換に固定小数点を用いた演算を使用します。標準座標系は、1.5 倍密度ディスプレイで表示する際に以下のような変換を行う"ceiling"関数を用いて拡縮されます。

標準 ネイティブ
1 2
2 3
3 5
4 6
5 8
6 9

アプリケーションが標準座標系を用いている状態で線やピクセル、あるいはビットマップを等間隔にしたい場合、座標は偶数の標準ピクセル数だけ離れている必要があります。例えば、標準座標系で3ピクセルおきのシーケンス( 1, 4, 7, 10, ... )は、ネイティブピクセルで 4 または 5 ずつ離れて連続する等間隔でない値のシーケンス( 2, 6, 11, 15, ... )に拡大されます。一方、標準座標で 2 ピクセルずつ離れたシーケンス( 1, 3, 5, 7, ... )は、一貫して 3 ネイティブピクセルずつ離れたシーケンス( 2, 5, 8, 11, ... )に拡大されます。

NOTE

拡縮のアルゴリズムは、Palm OS Cobalt では少し異なっています。詳細についてはこのセクションの脚注2を参照して下さい。

矩形は別のアルゴリズムを用いて拡縮されます。このアルゴリズムでは、拡大した矩形を縮小した場合に元の矩形と一致するよう、基点と各辺の長さの一貫性が保たれます。

フレームにおいて標準座標を使用する場合、ウィンドウマネージャは"floor"関数を使用します。これは 1.5 倍密度ディスプレイにおいて、値を以下のように拡大します。

標準 ネイティブ
1 1
2 3
3 4
4 6
5 7
6 9

プッシュボタンやグラフィックボタンは、フレームの端を共有する矩形で構成されるUI コントロールです。1.5 倍密度ディスプレイで発生する丸め誤差によるズレを避けるには、ボタンの topLeft.x に標準座標で偶数の値をセットし、水平方向に並べてあるボタンであれば幅に、垂直方向に並べてあるボタンであれば高さに、それぞれ標準座標で奇数の値をセットします。これにより、隣のフレームの上端だけでなく、並べて置かれている全てのボタンフレームが不揃いな表示になるのを避けることができます。これらのルールは、列や行が1つ以上の端を共有しているようなプッシュボタンの列に適用されるべきです。

※訳注

垂直方向に並べてあるボタンなら、「topLeft.y に標準座標で偶数の値をセット」しなければならない気がしますが、そこまで言及されていません。ちなみにこの段落の後半部分、上手く訳せなくて意味不明です。厳密な意味については、申し訳ありませんが原文にあたって下さい。

低密度ビットマップが 1.5 倍密度のビットマップに転写される場合、描画エンジンはそれぞれの行を1ピクセルおきに2倍し、次に1行おきに2倍にします。アプリケーションは必ず低密度ビットマップを用意しなければならないことに注意して下さい。描画エンジンは 1.5 倍密度から倍密度への拡大を行ないません。逆もまた同様です。

WARNING!

描画エンジンが倍密度のデータ(テキストまたはビットマップ)を 1.5 倍密度のビットマップへ、あるいは 1.5 倍密度から倍密度へ描画したときの挙動は未定義です。低密度のフォントやビットマップの高密度( 1.5 倍密度や倍密度 )への描画は期待どおりに動作します。

アプリケーションが最高画質のビットマップを提供する必要がある場合、サポートされる全ての密度のビットマップをまとめたビットマップファミリをアプリケーションに含めるべきです。画質がアプリケーションサイズよりも重要でないならば、サポートされる密度の一部だけを含めることもできます(ただし、低密度だけは最低でも含める必要があります)。

高密度スクリーンを低密度のオフスクリーンウィンドウにキャプチャし、それをスクリーンに書き戻すようなアルゴリズムを避けましょう。そうした場合、縮小時にデータの欠落が発生し、さらにスケールを戻す際には歪みが発生します。そうする代わりに、WinCreateOffscreenWindow に nativeFormat 引数を与えてオフスクリーンウィンドウをアロケートします。これによってスクリーンと同じ密度のビットマップがオフスクリーン用にアロケートされます。

フォントはビットマップとして描画されるため、ビットマップに適用されるルールはアプリケーション定義のフォントにも同じように適用されます。

 

メンテナンス互換性

高密度ディスプレイフィーチャセットは、それを使わずに作成されたアプリケーションとでも最大限の互換性を確保するようにデザインされています。高密度スクリーンのハンドヘルドが低密度モードで動作する場合、ウィンドウのスケール属性にはハンドヘルドのスクリーン密度とデフォルト密度の比率がセットされます。これにより、ウィンドウマネージャはグラフィック要素の位置を示す低密度座標から描画エンジンが使用する高密度座標への変換を行ないます。低密度モードは全ての Palm ハンドヘルドのデフォルトなので、高密度スクリーン向けにデザインされていないアプリケーションは低密度でも高密度でも期待どおりに動作します。

オフスクリーンウィンドウはデフォルトでは低密度ビットマップでアロケートされます。そのため、高密度ディスプレイフィーチャセットのことを知らないアプリケーションによるオフスクリーンビットマップの直接操作は、低密度スクリーンでも高密度スクリーンでも一貫性を保つことができます。

一方、高密度ディスプレイフィーチャセットを使用しているアプリケーションは、高密度ディスプレイを持たないハンドヘルドでも一貫性を保つために、低密度と高密度の両方のビットマップを含める必要があります。

Sony CLIE のいくつかのハンドヘルドは、高密度ディスプレイフィーチャセット無しで倍密度スクリーンを実現しています。高密度ディスプレイフィーチャセットはこれらのハンドヘルド向けに作成されたビットマップを認識し、倍密度ビットマップとして正しく表示できます。

非互換性の1つは、ハンドヘルドのスクリーンに直接アクセスするアプリケーションによって生じます。スクリーンに直接アクセスするような高密度スクリーン未対応アプリケーションが高密度スクリーンにアクセスすると、予期しない結果が生じます。例えば、160 x 160 と想定したスクリーンのピクセルを直接操作するようなアプリケーションが 161 番目のピクセルを変更すると、それは最初の行の中央付近のピクセルを変更したことになり、2行目の最初のピクセルを操作したことにはなりません。同様に、ハンドヘルドのプロセッサが ARM ベースの場合、ARM ベースのプラットフォームと 68K 系プロセッサ間のエンディアンの違いによって不適切な描画が行なわれることになります。

 

テキスト

Palm ハンドヘルド はスクリーンの密度にあわせたシステムフォントを有しています。デフォルトでは、アプリケーションがハンドヘルドの高密度機能について知らない場合でも、常にテキストは可能な限り最良の密度で描画されます。高密度フォントのメトリックは低密度システムフォントと一致します。

システムフォントはスクリーンの密度にあわせてあるため、描画エンジンはテキストをスクリーンに描画する際に拡大を行う必要がありません。しかし、高密度スクリーンを持つハンドヘルド上で動作するアプリケーションが低密度のオフスクリーンウィンドウをアロケートし、なおかつ低密度フォントが利用できない場合、描画エンジンは高密度フォントのビットマップを縮小します。結果的に、そのオフスクリーンがピクセルレベルで2倍に拡大されて高密度ディスプレイに転写されると、低品質なテキストが描画されることになります。低密度フォントが利用できる場合、描画エンジンは可能な限りもっとも見栄えの良い結果を出力するため、低密度フォントを使用してテキストを描画します。

訳注

おそらく、ここで言っているのは、低密度オフスクリーンに描画する場合、描画エンジンが高密度フォントを縮小した結果よりも、低密度フォントがあるならそちらを使った方が見栄えが良いのでそうしている、ということだと思います。訳出がマズいせいで伝わらないといけないので、念のため。

描画エンジンは以下の順序で使用するフォントを選択します。

  1. 対象の密度に合致するフォントがあればそれを選択します。
  2. 対象の密度の半分の密度のフォントがあればそれを選択します。
  3. もっとも近い密度のフォントを選択します。近さが同じであれば低い密度が優先されます。

この挙動は、アプリケーションが一度により多くのテキストを表示するために変更することができます。WinSetScalingMode 関数は描画エンジンに対し、後続のテキスト描画で低密度フォントを拡大せずに使用することを強制できます。この機能は WinSetScalingMode 関数をサポートする最近の Palm OS を搭載した高密度ディスプレイのハンドヘルドでのみ使用できることに注意して下さい。

フォントマネージャはオフスクリーンウィンドウの描画ステートにおける stdToActiveScale フィールドをフォントメトリックの変換に使用します。高密度座標でテキストを描画するためには、フォントマネージャ関数を使用してテキストの位置合わせやフォントメトリックの抽出をする前に WinSetCoordinateSystem 関数をコールして高密度座標系に変更します。

描画エンジンはデフォルトで文字グラフィックを標準座標上に並べます。この挙動は単密度および倍密度のディスプレイではうまく動作しますが、1.5 倍密度のディスプレイでは文字間が不均等に見えてしまいます。これは描画エンジンが 1.5 倍密度のディスプレイにおいて標準座標上に文字グラフィックを並べる際、文字間に"パディング"—— 追加のスペース文字 —— を追加しなければならない場合があるためです。この挙動は WinSetScalingMode によって変更できます。これにより、文字グラフィック間にパディングを追加することなく描画するため、テキストの文字間はより狭くなります。しかし、このパディングなしの状態はテキストの見栄えは良いのですが、それをするためにはアプリケーションが高密度座標系を使用できなければなりません。

高密度スクリーンでは、下線モードは常に高密度パターンを使って描画されます。

ユーザーインターフェースにおけるテキストの使用に関する詳細な説明は、「8 テキスト」 を参照して下さい。フォントの選択や使用、および作成についても説明しています。「8-4 フォント」 を参照して下さい。

 

線と矩形

倍密度スクリーン上で標準座標系を使って線や矩形を描画する場合、グラフィック要素は improved resolution で描画されます。この挙動はオフスクリーンウィンドウに(またはオフスクリーンウィンドウから)描画した場合の一貫性のない表示を避けるためと、画素間の意図しない重なりやすきまを防ぐためです。

訳注

improved resolution に適切な訳語をあてはめることができません。おそらくは、上記の条件下で描画される線の太さのことを言っているのだと思います。しかし、辞書的な訳だと全体の意味が通らなくなってしまうような気がするので、ひとまず保留とします。

他のグラフィック要素でも、ウィンドウマネージャは描画エンジンをコールする前に座標系の変換を行ないます。この変換では、線の座標だけでなく矩形の左上座標や長さも対象になります。

図 4.1 の左側は、標準座標系でスクリーン上の (2,1) から (6,3) に対角線をひいた結果です。右側は、同じ線を以下のコードでスクリーンのネイティブ座標系で描画した結果です。

WinPushDrawState();
oldScale = WinSetCoordinateSystem(kCoordinatesNative);
WinDrawLine(2, 1, 6, 3); // x1, y1, x2, y2
WinPopDrawState();

 

NOTE

これらの図では、左上の座標が倍密度スクリーンの基点である (0,0) になります。

図 4.1 標準座標系(左)とネイティブ座標系(右)を使用して描画した対角線

 

左上座標が (1,1)、幅が (4,4) の矩形を倍密度スクリーンの標準座標系とネイティブ座標系で描画した結果を図 4.2 に示します。

図 4.2 標準座標系(左)とネイティブ座標系(右)を使用して描画した矩形

 

角が丸い矩形が倍密度ディスプレイに標準座標系で描画される場合、同じようにピクセルレベルで倍に拡大されます。倍密度モードでは、角の丸い部分はネイティブの倍密度座標で描画され、結果としてより精緻な描画になります。

 

パターン

以前のバージョンの Palm OS では、パターンは 1 ビットの深度で 8 x 8 ビットで表現されていました。高密度のパターンをサポートするには、新しいウィンドウマネージャ関数である WinPaintTiledBitmap を使用します。この関数を使えば、ビットマップ引数に任意のパターンを指定して矩形を塗り潰すことができます。

パターン付きの線や矩形の塗り潰しを描画する際、パターンは描画エンジンによって描画先のビット深度に拡張されます。パターンを最適な密度で描画するため、描画エンジンはパターンビットマップと描画先ビットマップの density フィールドを使用します。これにより、アプリケーションが低密度と高密度のパターンを定義することが可能になります。

標準の PatternType である grayPattern を補うために、高密度ディスプレイフィーチャセットは lightGrayPattern と darkGrayPattern という2つのグレイパターンを追加で定義しています。これらのパターンを図 4.3 と図 4.4 にそれぞれ示します。

図 4.3 ライトグレイパターン

 

図 4.4 ダークグレイパターン

 

これら3つの標準グレイパターンは灰色の表現を向上させるため、描画エンジンによって常にスクリーンの密度で描画されます。しかし、カスタムの 8 x 8 パターンは描画エンジンによって、kDensityLow と描画先の密度の比率をもとに適切な大きなに引き延ばされます。

 

 

 

← 1 節に戻る ↑4 章トップへ 3 節に進む →

 

 


Copyright(C) 2005-2017 project-enigma.
Generated by CL-PREFAB.