最善のグラフィック・オブジェクトの選択

JViews Framework には、いくつかの定義済み IlvGraphic サブクラスが含まれています。これらは、異なる機能およびメモリー/速度特性を持っています。ただし、場合によっては、アプリケーション用にカスタム・グラフィック・オブジェクトをプログラムすることが最善の選択になります。定義済みグラフィック・オブジェクトには、アプリケーションで不要になる可能性のある大きな汎用セットの機能が含まれるためです。

テキスト・オブジェクト

IlvLabelIlvZoomableLabel、および IlvText の各クラスは、テキストの表示に使用することができます。IlvLabel は、最も高速で軽量のテキスト・オブジェクトですが、ズーム可能でも回転可能でもなく、複数行のテキストをサポートしません。機能はほとんどありません。IlvZoomableLabel は、ズーム可能、回転可能で、複数行のテキストをサポートします。グリフを階調ペイントまたはテクスチャー・ペイントでペイントします。このためペイントの速度は比較的に遅く、多くのメモリーを使用します。IlvText は、多くの場合、IlvZoomableLabel よりはるかに高速ですが、テキスト・グリフの描画に同一色しかサポートしません。属性テキスト (下線、取り消し線など) および複数行折り返しは、サポートします。ほとんどの場合、IlvText は、IlvZoomableLabel よりも優れていますが、多くのメモリーを使用します。
クラス名 描画 メモリー使用量 ズーム可能回転可能 絵文字塗りつぶし 背景矩形の塗りつぶしおよび描線 複数行 高度な機能 (属性テキスト、行折り返し)
IlvLabel 最高速 非常に軽い No No No No
IlvZoomableLabel 低速 重い Yes ペイント Yes Yes No
IlvText 中速 重い Yes Yes Yes Yes
アンチエイリアシングが無効になっていると、IlvLabelIlvText、および IlvZoomableLable の描画速度が増します。速度を重要視する場合は、アンチエイリアシングをオフに切り替えるのが賢明です。
label.setAntialiasing(false);
IlvText および IlvZoomableLable は、多くの機能を持ち、多くのメモリーを必要とするので、汎用クラスとして設計されています。メモリーを重要視し、多くのテキスト・オブジェクトまたはラベル・オブジェクトがある場合で、しかもこれらのオブジェクトのうちのわずかな機能しかカスタマイズ可能である必要がない場合、これらのわずかな機能しか含まない軽量テキスト・クラスを実装するのが賢明です。軽量テキスト・クラスの実装は、オンザフライで一時割り振り IlvText に代行させることができます。このメカニズムの例は、コード例 <installdir>/jviews-framework89/codefragments/lighttext に示しています。

形状オブジェクト

IlvGeneralPath は、塗りつぶし形状または描線の形状の描画に使用できる汎用オブジェクトです。ただし、特定の形状用に特殊化され、高速で使用メモリーの少ないクラスがあります。こうした特殊化されたクラスは、IlvGeneralPath より機能が少なくなっています。例えば、カスタム線をサポートしません。
  • 直線を描くための IlvLine
  • 一連の直線セグメントを描くための IlvPolyline
  • 一連のスプライン・セグメントを描くための IlvSpline
  • 塗りつぶしまたは描線の矩形 (オプションで丸みのある角) を描くための IlvRectangle
  • 塗りつぶしまたは描線の多角形を描くための IlvPolygon
  • 扇形、同心円、または円を描くための IlvArc
  • 塗りつぶしまたは描線の円または楕円を描くための IlvEllipse
これらのクラスがアプリケーションのニーズに合う場合、IlvGeneralPath の代わりに使用するようにお勧めします。

アイコンおよびイメージ

Rogue Wave® JViewsでは、GIF、JPG、および PNG イメージを読み込むことができ、また制限付きながら SVG および DXF イメージも読み込むことができます。GIF、JPG、および PNG は、IlvIcon に読み込まれるビットマップ形式です。SVG および DXF は、IlvGraphicSet (例えば、get 経由で JViews Diagrammer 内) に読み込めるベクトル形式です。ビットマップをズームすると、描画品質が落ちます。例えば、拡大されたビットマップは不鮮明になります。ベクトル形式ではこの影響は出ません。影響なしにズームすることができます。ただし、ベクトル形式の場合、ビットマップよりも多くのメモリーが使用され、描画速度が遅くなる場合があります。3 つの矩形と 4 つの円からなるイメージを表示する 10000 のノードがあると想定します。このイメージをビットマップとして読み込むと、このイメージは 10000 すべてのノードの間で自動的に共有されます。 イメージを SVG または DFX ファイルとして読み込んだ場合、IlvGraphicSet の 10000 のインスタンスができ、それぞれが 3 つの矩形と 4 つの円を含むので、全体で 30000 の矩形と 40000 の円を含みます。つまり SVG または DXF ファイルを持つこうしたノードを実装する場合、ビットマップ・イメージで実装する場合より多くのメモリーが必要になります。多くの外部 SVG ツールは、非常に複雑になることが考えられる最適化されていない SVG コードを作成する可能性があります。こうしたツールは、1 回使用されるイメージを作成するのには適していますが、10000 ノードで 10000 回複製されるようなイメージを作成するのには適していません。 したがって、多数のノード内部で SVG を使用する場合、SVG を微調整して単純化するか、代わりにビットマップ・イメージを使用するようにお勧めします。 ズームされたビットマップでの品質の劣化を克服するために、IlvIcon には、高品質のレンダリング・モード (setHighQualityRendering) があります。ただしこの描画モードは、非常に時間を消費します。多くのアイコンを表示する必要がある場合、パフォーマンスの向上のために高品質のレンダリング・モードを無効にするようにお勧めします。
メモ
JViews Diagrammer IlvGeneralNode は、必要に応じて内部的に IlvIcon を使用し、デフォルトで低速の高品質レンダリング・モードに設定します。この効果を無効とするには、最初の IlvGeneralNode が割り振られる前、すなわちアプリケーションの開始部分で
IlvGeneralNode.High_Quality_Icons = false;
を呼び出します。

リンク

Rogue Wave JViews は、ダイアグラム内のノードに接続する多くのリンク・クラスを提供します。最も単純なリンク・クラスは IlvLinkImage で、最も複雑な (機能が豊富であるが、低速な) リンク・クラスは、JViews DiagrammerIlvGeneralLink です。機能、メモリー、および速度を条件にすると、以下の式が成り立ちます。
IlvLinkImage << IlvPolylineLinkImage < IlvEnhancedPolylineLinkImage << IlvSimpleLink (Diagrammer) << IlvGeneralLink (Diagrammer)
アプリケーションで多くのリンクが使用される場合、必要とする機能を持つ可能な限り最軽量のリンクを使用するようにお勧めします。
  • IlvLinkImage は、単純矢印と同一色で表される直線リンクとして適しています。JViews Diagrammer で使用可能なリンクの形状を変更する自動グラフ・レイアウト・アルゴリズムを適用する場合は、これを使用しないでください。
  • IlvPolylineLinkImage は、曲折点を使用するリンクです。これは、単純矢印と同一色を持ち、すべてのグラフ・レイアウトで使用できます。
  • IlvEnhancedPolylineLinkImage は、IlvPolylineLinkImage のすべての機能を備えています。さらに単純逆向き矢印を表示でき、直交とバンドル・モードを持ち、トンネル/ブリッジの交差を表示できます。
  • IlvSimpleLink は、SDM で必要になることがあるプロパティー通知をサポートする IlvEnhancedPolylineLinkImage です。
  • IlvGeneralLink は、IlvSimpleLink のすべての機能を備えていますが、任意の装飾とラベル、および各種非同一色を使用可能です。
  • IlvCompositeLink は、前述のリンクのすべての機能を備えていないため、この機能階層に適合しません。ただし、前述のリンクの 1 つを使用して構成することができます。メモリーに関しては、IlvCompositeLink は、最も重いリンクです。速度に関しては、その構成部分によって決まります。
IlvClippingLinkConnector を使用し、速度を上げたい場合、常に IlvPolicyAwareLinkImage のサブクラス (例えばIlvEnhancedPolylineLinkImageIlvSimpleLink、または IlvGeneralLink) を使用します。リンク・コネクターはこれらのクラスのクリップ・ポイントをキャッシュできるが、他のリンク・クラスのクリップ・ポイントはキャッシュできないためです。クリップ・ポイントがキャッシュされないと、リンクの描画時にオンザフライでそれを再計算しなければならないため、速度が遅くなる可能性があります。
クワッドツリーが有効になっている場合、ズーム可能リンクの描画および取り扱いは、ズーム不可リンクよりも速くなります (「zoomable」を参照)。 アプリケーションで多くのリンクが使用される場合、ズーム可能リンクを使用するようにお勧めします。IlvGeneralLink はズーム可能ではありませんが、他のリンクは、その終了ノードがズーム可能である場合にのみズーム可能です。アプリケーションが膨大な数のリンクを表示する必要がある場合、ズーム可能なノードおよびリンクのみを使用するようにお勧めします。特にトンネル/ブリッジの交差形状 (IlvEnhancedPolylineLinkImageIlvSimpleLink、および IlvGeneralLink のもの) を使用する場合、ズーム可能リンクを使用してください。こうした場合、リンクの交差をオンザフライで計算する必要があるためです。クワッドツリーは、こうした交差の判別に役立ちますが、これが機能するのは、クワッドツリーが有効になっていて、リンクがズーム可能である場合のみです。クワッドツリーを無効にする必要がある場合や、多数のズーム不可リンクを使用する必要がある場合、トンネル/ブリッジの交差形状を無効にするようにお勧めします。

入れ子マネージャーと入れ子グラファー

マネージャー (IlvManager) またはグラファー (IlvGrapher) が階層で入れ子になっていると、この階層が深くなれば、パフォーマンスは低下します。 入れ子が極端に深い (100 以上のレベル) 入れ子グラフは、使用しないでください。
入れ子グラファーがある場合、グラフ間リンク、つまり異なるグラファー内の終了ノードとのリンクが可能になります。グラフ間リンクは、同じグラファー内の終了ノードとの通常リンクよりも効果がしばしば低くなります。リンクのジオメトリーを計算するときに、異なるグラファーの異なるトランスフォーマーを考慮に入れる必要があるためです。グラフ間リンクの使用を避け、通常リンクのみが必要となるようにダイアグラムを構造化することで、速度を最適化することができます。

カスタム・グラフィック・オブジェクトの実装

速度およびメモリー使用量を最適化する最も効果的な方法は、アプリケーションで必要な機能だけを含むカスタム・グラフィック・クラスを実装することです。これにより、カスタム・グラフはアプリケーションで変化するパラメーターだけを格納すればよいので、メモリーが削減されます。汎用定義済みグラフィック・クラスとは対照的に、他のすべての機能 (カラー、ペイント、描線など) は、アプリケーション内で変化する必要がないので、ハードワイヤードにすることができます。ハードワイヤード機能は、オブジェクトごとに格納する必要がないので、メモリーを必要としません。
複数の状態を持ち、異なる方法で描画する必要があるグラフィック・オブジェクトを実装するために、2 つの戦略があります。
  • IlvRectangleIlvEllipseIlvText などの複数のサブオブジェクトを持つ IlvGraphicSet または IlvCompositeGraphic を構成し、これらのサブオブジェクトを状態に応じて再配置します。これにより、これらのサブオブジェクトが状態に応じて可視になったり、非可視になったりします。
  • 状態に応じて異なるビットマップ・イメージを表示するだけのカスタム・グラフィックスを作成します。状態ごとに、1 つしかビットマップ・イメージは必要ありません。
多くの場合、オブジェクトは多いが、状態は少なければ、2 番目の戦略では使用メモリーが少なくなります。イメージがすべてのオブジェクト間で共有できるためです。一方最初の戦略では、メイン・オブジェクトごとに個別のサブオブジェクトが必要になります。定義済みクラス IlvMultipleIcon は、2 番目の戦略の実装に役立ちます。
カスタム・グラフィックスを実装する際には、速度に対して以下のメソッドを最適化する必要があります。使用頻度がごく高いためです。
boundingBox(IlvTransformer) 内部で重い計算が必要な場合、トランスフォーマーをバウンディング・ボックスにマップするキャッシュの実装を考えてください。オブジェクトの実際のバウンドが変更された場合 (例えばオブジェクトのサイズまたは位置の影響でオブジェクト・パラメーターが変更された場合)、必ずバウンディング・ボックス・キャッシュを無効にする必要があります。トランスフォーマーがキャッシュにない場合は、バウンディング・ボックスを再計算する必要があります。ただし、トランスフォーマーが既にキャッシュにある場合は、バウンディング・ボックスは、キャッシュから取得することができるので、操作の速度が増します。
カスタム・グラフィック・オブジェクトの実装方法について詳しくは、「新規グラフィック・オブジェクト・クラスの作成」を参照してください。<installdir>/jviews-framework89/samples/graphics サンプルは、カスタム・グラフィック・オブジェクトを作成する方法を示します。コード例 <installdir>/jviews-framework89/codefragments/lighttext は、軽量カスタム・テキスト・オブジェクトの作成方法を示しています。