Macintosh Developer Online (MDOnline)

2002年3月5日発行号 - Javaでベンチマーク

ちょっと遅くなってしまいました。Javaのベンチマークを作っていたら、はまってしまいました。ほんとうは、Swingのコンポーネントを使ったベンチマークもしたかったのですが、明日の号に回します。
今日は、ハローワークに行ってきました。仕事をしているのに職安へ行くのか？とお叱りになる方もいらっしゃるでしょうけど、マジで今月は収入がありません。離職票は昨日もらったので、1日でも早く行った方がいいわけですから、すぐに行きました。午前中に済まそうと思っていたら、受付は11時までなんですよねぇ。そういえば、以前に法務局に行ったときも窓口のしまる時間が意外に早かったので面喰らいましたけど。午後一番に行って、手続きはすぐに終わりましたが、なんか時間ばっかり使ったという感じです。勤続12.5年で会社都合の解雇ですから、いわゆるすぐにもらえるパターンのようです。もちろん、これまでの給与相当の全額がもらえるわけじゃないのですけどないよりはあった方がいいですからね。だけど、雇用保険については来週に説明会があってそれに行かないといけません。最初の失業手当ては4月上旬になってしまうんですね。なんか、ハローワークは何度も足を運ばないといけないのは、場所的に中途半端なこともあってちょっと面倒っぽいです。
MDOnlineでいろいろ連載を始めてしまいましたけど、結局どれも中途半端になりそうで、大変申し訳ありません。せめてがんばっていくつかは書籍にしたいなと考えています。MDOnlineを発行しながら書籍化し、収入をアップさせるというのが目論見でしたが、そのときには読者特別販売を2割引でするなどの手配をしているところでした。なのですが、今回はそれも水の泡ですね。そのためのコンビニ決済も準備していたのです。いずれにしても、書籍化したときには、お知らせをしたいと思います。サーバというかネットワークインフラについても、実は先月末の時点でもしかして近々落とされるかもといった事態になりそうだったのですが、それも大丈夫なことが判明したので、それも一安心です。解雇から1週間、やっと落ち着いてきたという感じです。
（新居雅行 msyk@mdonline.jp）

【MacWIRE配信予定】小池邦人のプログラミング日記》2002/3/4　ウィンドウのグループ化　その2

　　　この記事のPDFファイル（687KB）は以下のアドレスにあります。
　　　ダウンロードには､MDOnlineのアカウントが必要です｡
　　　pdfs/MDOnline020017.pdf
　‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥
今回は、ウィンドウのグループ化の話の続きとなります。ウィンドウタイトルに配置できるようになったToolBarボタンの利用方法についても解説します。

Carbonアプリケーションの開発で、すべてのリソースと縁を切ることは無理なのですが、Nibファイルのおかげで、ダイアログとメニューについてはリソース編集をする機会はなくなりました。ただし、大きな問題は、Nibファイルを編集するツールが現状ではInterface Builderしかないことです。このアプリケーション、使っていると操作に対する反応速度がどんどん鈍くなっていきます。ポップアップメニューやグループ・ラジオボタンの編集では、オブジェクトをちょっと移動するだけでレインボーカーソルが10秒ぐらい回りっぱなしになります。21世紀の世の中、如何様にするとこんなに反応が遅いアプリケーションが開発できるのか？大きな疑問です。うちだけなのか？日本語環境との相性なのか？ガーベージコレクションをしてるのか？CocoaフレームワークにボトルネックAPIがあるのか？Nibファイルのデータ構造がバカなのか？Interface Builderのデータハンドリングがタコなのか？とにかく、最近のストレスの大部分は、Interface Builderでの作業に集中しているわけです（涙）。

さて、Mac OS Xから新しく採用されたToolBarボタンを利用する「Group_Demo2」サンプルアプリケーションを紹介しましょう。ToolBarボタンはウィンドウの右上に表示されます。Mac OS X 10.1のFinderでは、このボタンをクリックすることで、ウィンドウ上部のツールバーを出し入れすることが可能です。

　

ただ残念なことに、現在のCarebonフレームワークではツールバーを操作するためのシステムモジュール（ToolBar Manager？）は提供されていません。Cocoaフレームワークには、これを操作するためのクラスライブラリが用意されています。興味がある方は、Developer/Examples/AppKitフォルダの「SimpleToolbar」とういうCocoaベースのプロジェクトを参考にしてみてください。そんなわけで、CarbonアプリケーションにとってToolBarボタンは「宝の持ち腐れ」に近い状態なのですが、それ自体をハンドリングすることは可能です。ToolBarボタンは、CloseボックスやZoomボックスと同じようにCarbon Event Handlerルーチンでハンドリングします。

サンプルアプリケーションを起動すると、ウィンドウがひとつオープンします。ここで、ToolBarボタンをクリックすると、画像表示の部分が持ち上がり、スライダーとボタンを表示している領域を隠します。

　

もう一度クリックすると、上がった領域が元に戻り、スライダーとボタンが復活します。「終了」ボタンをクリックするとアプリケーションを終了できますが、スライダーの方はダミーであり、機能は何も割り付けてありません。

　

実は、ウィンドウのコントロールを表示している部分（ツールバー）と画像表示の部分は、別々のウィンドウで構成されています。両ウィンドウをグループ化することにより、あたかもひとつのウィンドウのように見せているわけです。それでは、このサンプルアプリケーションのmain()ルーチンを見てみます。

　

Nibファイルから、ツールバー部分のウィンドウ（ToolBarWindow）と、画像表示部分のウィンド（DisplayWindow）の両方を読み込んでいます。どちらのウィンドウもCreateWindowGroup()で作られたウィンドウグループに属します。DisplayWindowの方をSelectWindow()で選択したら、ChangeWindowGroupAttributes()でグループのアトリビュート（性質）を変更し、グループ間の上下関係（レイアー）がマウスクリックで変わらないように設定します。ToolBarボックスがクリックされた時の処理は、setUpWindowEvent()でインストールされたCarbon Event Handlerが行います。この時、setUpWindowEvent()にはDisplayWindowのWindowRefも渡しておきます。これにより、このWindowRefはユーザデータ（UserData）としてHandlerルーチンでも参照できるようになります。

　

ふたつのEventTypeSpecのうち、イベントクラスがkEventClassWindowでイベント種類がkEventWindowToolbarSwitchModeの方が、ToolBarボックスのクリックに対応した物です。処理を担当するmyWindowEventHandler()は以下のようになります。

　

DisplayWindowのWindowRefはユーザデータ（userData）に代入されてきます。ToolBarボタンのクリックでDisplayWindowを上下移動させにはTransitionWindow()を使います。移動後の状態は、static変数のw_dirに保存されますので、次回のクリックでは逆方向への移動が可能になるわけです。DisplayWindowを移動させる時には、ChangeWindowGroupAttributes()で「すべてを同時に移動させる」アトリビュート（kWindowGroupAttrMoveTogether）を解除しておくことを忘れないでください。そうしないと、TransitionWindow()により両方のウィンドウが同時に移動してしまいます。解除したアトリビュートは、移動が終了した時点で再度設定し直します。この処理を忘れると、タイトルバーのドラッグでウィンドウを移動させた時に、DisplayWindowだけ移動せずに、その場に置き去りにされてしまいます。

ここで解説した「Group_Demo2」サンプルアプリケーションは、以下のサイトに登録されていますので試してみてください。Mac OS X 10.1と最新版のDeveloper Toolsが必要です。

　http://www.ottimo.co.jp/library/

次回は、Overlayウィンドウの使い方を解説します。Overlayウィンドウとは、Mac OS Xから採用された機能で、Quartz 2Dを使い半透明のオブジェクトをモニタ上に表示することが可能です。

∽∽∽∽∽∽∽この項、以上∽∽∽∽∽∽∽[小池邦人/オッティモ]∽∽∽∽∽∽∽

関連リンク：オッティモ
カテゴリ：ユーザインタフェース, Carbon/CF, 小池邦人のプログラミング日記

Java Watch on the X》5 _ ハードウエアアクセラレータをチェック(1)-1

　　　この記事のPDFファイル（672KB）は以下のアドレスにあります。
　　　ダウンロードには､MDOnlineのアカウントが必要です｡
　　　pdfs/MDOnline020016.pdf
　‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥‥
Mac OS XのJava 1.3.1 Update 1が、2002年2月にリリースされた。いくつかのアップデート機能があるが、その中の1つに、ハードウエアアクセラレータによるSwingアプリケーションの高速化がある。アクセラレーションを有効にする方法の解説と、加えて、グラフィックスを利用するようなサンプルプログラムを作ってベンチマークテストをしてみた結果を説明しよう。

――――Javaのアクセラレーション機能
Mac OS XはJava VMを搭載したことを大きな特徴としてプッシュしてはいるものの、残念ながら、日本のユーザに取っては、テキストフィールドがあるとアプリケーションの応答が極端に悪くなるといったことなどがあって、JavaすなわちSwingを使ったアプリケーション作成を本格的に行うことはできなかった。しかしながら、Java 1.3.1 Update 1によって完全ではないとしても、十分に使えるレベルにはなりつつある。日本のプログラマにとっては、やっと様子見をしなくても済む段階まで来た。そのJava 1.3.1 Update 1での新機能がハードウエアアクセラレーションだ。実際にはそれよりも前から機能自体は組み込まれていた。これまでは、「デベロッパ向けのプレビュー」という位置付けでもあり、そうした機能が今後利用できるという予告編のようなものであった。だが、Java 1.3.1 Update 1ではそれが正式な機能としてリストアップされたのである。
ハードウエアアクセラレーションは、Swingのさまざまな処理を、グラフィックスカードを直接利用して処理をすることで、アプリケーション全体の処理能力を高めようというものだ。Javaの場合には、やはり仮想マシンベースであることや、AWTの上にSwingがあるといった多階層化されたフレームワークでもあり、速度的には確かに不利であることも言えるだろう。そこで、Swingの処理を、いわば、グラフィックスのハードウエアを直接利用することで高速化を試みるのである。
ただ、それでは、実際にどういう処理がアクセラレートされるのかといった情報は今のところ得られていない。たとえば、処理のどの部分に高速化がかかるのかや、さらにはAWTの処理まで高速化はあるのかどうかといったことが一切分からない。Java 1.3.1 Update 1のドキュメントでは、Swingのグラフィックス呼び出しがハードウエアを直接利用するとしているという記述しか見られないのである。だから、逆に、この機能をうまく引き出すということや、この機能が適合する処理はどんなものがあるかといったことも判断しようがない。
さらに、ハードウエアアクセラレーションは、グラフィックスカードないしはグラフィックスチップごとに、利用する／しないを指定する形式になっている。単純なオン／オフではなく、たとえばATI Rageでは利用しないけどGeForceでは利用するといった設定が可能になる。ただし、何でもいいからすべてオンにするということはできない。これについても、「効果のないカードでは指定をしないことを可能にする」という記述が見られるが、つまりは、アクセラレーションの効果がない場合が存在するということの裏返しではないかと想像される。

――――アクセラレーション機能の有効化
ハードウエアアクセラレーションを有効にするには、システムプロパティの

com.apple.hwaccellist

に対して、適用させたいグラフィックカードに対応したキーワードを設定する。カードごとに、以下のようなキーワードが定義されている。ここでも問題があって、機種ごとの対応カードについての情報がわずかしかないのである。

ビデオカード：キーワード
ATI Rage128（16MB）：ATIRage128_16777216
ATI Radeon（16MB）：ATIRadeon_16777216
ATI Rage128（32MB）：ATIRage128_33554432
ATI Radeon（32MB）：ATIRadeon_33554432
NVidia GeForce2（32MB）：NVidia11_33554432
NVidia GeForce3（64MB）：NVidia20_67108864
NVidia GeForce4（64MB）：NVidia20_134217728
PowerBook G4など？：ATIRage128_8388608

Java 1.3.1 Update 1のドキュメントでは、一覧表が掲載されているが、たとえば、PowerBook G4 500MHz機の場合のキーワードが掲載されていないなど、実際に使えるキーワードの全てが掲載されているとは限らないようだ。
Appleは、現在起動しているマシンでのビデオカードについての情報を得る、hwaccel_info_toolというコマンドライン形式の診断ソフトを提供している。ただし、これについては、入手できるのは現段階ではADCメンバーだけなので、こうしたツールの存在があることだけをお伝えしておこう。たまたま、筆者がPowerBook G4を持っていたのでドキュメントのリストにあるもの以外のキーワードを見つけられたのかもしれないが、いずれにしても、どの機種ではどのキーワードを適用できるのかと言った一覧表は必要になるだろう。
実際にプロパティを設定するには、Project Builderで、パッケージ形式のアプリケーションを作成しているのであれば、「プロジェクト」メニューから「アクティブターゲットの編集」（Command+option+E）を選択し、「アプリケーション設定」のタブを選択する。そして、「詳細設定」ボタンをクリックして、設定項目の階層表示を行う。Java、Propertiesと階層をたどり、Propertiesの項目を選択して「下位に新規項目」というボタンをクリックする。

◇プロパティ設定を追加する
　

すると、新しい項目が作成されるので、左側は「com.apple.hwaccellist」と指定し、右側はグラフィックスカードに対応したキーワードを指定する。右側のキーワードは、カンマで区切って複数指定が可能だ。だから、すべてのマシンでアクセラレートの機能を有効にするには、すべてのキーワードをカンマで並べれば良い。

◇アクセラレートを有効にするプロパティを設定する
　

‥‥‥‥‥‥‥この項、続く‥‥‥‥‥‥‥[新居雅行]‥‥‥‥‥‥‥

カテゴリ：Java, Java Watch on the X

Java Watch on the X》5 _ ハードウエアアクセラレータをチェック(1)-2

――――ベンチマークを行ってみた
さて、実際にベンチマークテストを行ってみた。「Swingが高速化される」というときのSwingの範囲が明確ではないため、はずしがあるかもしれないが、その辺りは要検討事項だろう。
テストプログラムは、JFrameのウインドウに、グラフィックスをたくさん表示するということをやってみた。グラフィックスとしては、パッケージのResourcesフォルダにある1つのJPEGファイル（1792×1184ドット、606KB）を、画面上に表示した。

◇テストプログラムの実行例
　

JFrameはnullレイアウトにして、座標をランダムに指定して、画像をたくさん表示するようにしている。1つ1つの画像は、Canvasを拡張したクラスで表示するようにした。その拡張クラスでJPEGファイルの表示を行うという具合であるが、画像の回りに、GraphicsクラスのdrawRectで10回ほどカラーをランダムに変更させて、ちょっとケバい枠を書いてみた。
ただ、ここで、「CanvasはAWTではないか」という話も出てくるだろう。だが、JPEG画像を手軽に表示するにはこの手法が使われるだろうから、まずはこれでチェックをしてみることにする。もし、AWTだとアクセラレーションがかからないのであれば、ベンチマークテスト結果は、プロパティの設定に関わらず変化がないはずである。ベンチマークテストは、ウインドウを表示後、Canvasを拡張したJPEG表示オブジェクトを100個ランダムに追加する時間を測定してみた。「追加」だから、厳密に言えば表示時間ではないのだが、体感と大きく離れた結果ではなかった。

◇テストプログラム
　http://mdonline.jp/figs/02/028/SwingAccelTest.sit

気になるテスト結果だが、「ほとんど効果はない」というところのようだ。実は、測定結果が、毎回大きく変動する。統計処理をしなければならないような変動なのである。数回測定した結果はアクセラレーションの指定があれば約8秒、ない場合には7秒となっているが、どちらの場合も最大と最小が2倍近い開きがあるので、事実上変化はないと考えられる。テストマシンは500MHzのPowerBook G4である。なお、ビルドしたアプリケーションをFinderでダブルクリックし、Consoleアプリケーションに測定結果を出力して、実行時間を測定した。他のアプリケーションは起動しないようにした。他のアプリケーションが起動しているような場合でもチェックしてみたが、その状況によって実行時間の数字自体がかなり増えてくる。
もちろん、これだけの結果ではすべては分からないというのは当然のことだろう。AWTのコンポーネントでは有効ではないということも言えるかもしれないが、アクセラレータを有効にすると、時折Consoleに「speed pen going down, clean up」と表示されるのが確認されるので、今回のベンチマークテストではアクセラレーションの機能はまったく使われなかったとも言えないと考えられる。これが、PowerBookだからということで、別のマシンなら早くなるのであろうか？　そのあたりはもちろん不明だが、もし、読者の方で、ベンチマークをしていただけるのであれば、測定結果をお知らせしていただければと思う。

なお、もう少し違うテストもやってみる予定である。

‥‥‥‥‥‥‥この項、続く‥‥‥‥‥‥‥[新居雅行]‥‥‥‥‥‥‥

カテゴリ：Java, Java Watch on the X