タイトル【小池邦人のプログラミング日記】2000/9/4＜Mac OS Xへの道　Carbon対応の実際（7）＞カテゴリーグラフィックス, Carbon/CF, 小池邦人のプログラミング日記
作成日2000/9/4 7:35:12作成者小池邦人
既存のソースコードをCarbon APIに対応させ、Mac OS X環境でも起動できるアプリを作るための工程のうち、今回は（9）のMac OS Xに対する最適化について解説します。今回で、このシリーズも最終回となります。

（9）Mac OS Xに対する最適化

Mac OS Xに対する最適化の最大の作業は、前回に説明した「Carbon Eventモデルへの変更」であることは言うまでもありません。その次に大きな作業を上げるとすれば、同じくCarbon環境で導入された「Multilingual Text Engine」（昔はMultilingual Text Editと言っていた）への対応でしょう。Multilingual Text Engineでは、今まで長い間Macintosh環境で利用されてきた「Text Edit」のAPI群を、まったく新しく作り直しています。旧Text Editには、扱える文字量が32K Byte以内だとか、Tabキー対応の実装が難しいとか、非常に沢山の制限がありました。「このAPIはダイアログのテキストカラムのような簡易テキスト入力にのみ用いるべきだ！」などとAppleは偉そうに言っていましたが、OSに添付されている標準テキストエディタの「SimpleText」でも、いまだにこれが利用されているのが現実です（笑）。

言い換えれば、長年待ち望んでいた「まともなText Engine」が、やっと登場したわけです。Macintoshの世界では、旧Text Editのできの悪さのため、かなり古くからもっと優秀なテキストハンドリング用エンジン（ライブラリ）が出回っていました。ワープロやテキストエディタを開発しているデベロッパーは、有償、無償を問わず、とっくの昔にそちらを利用しています。よって。いささか時機を逸した感もありますが、大量のテキストをハンドリングするアプリケーションを新規開発しなければならない方にとっては、採用を検討してみる価値はあると思われます。もちろん簡単なテキストハンドリングだけならば、Carbon環境でも旧Text Editが利用できます。これは、旧Event ManagerとCarbon Event Mnagerとの関係とまったく同じ状況です。

Multilingual Text Engineに関するサンプルソースコードは、「CarbonLib 1.1a4 SDK」の「Sample Code」フォルダ内の「SimplerText」にあります。ただし、このプロジェクトをコンパイル＆リンクして実行してみると、完成したアプリケーションではまともにテキストが入力できません（涙）。なにやらプロジェクトの同階層には「main.nib」なんてフォルダもあり、怪しさ百万馬力です（笑）。ひょっとするとMac OS X専用なのでしょうか？結局のところ、Carbon Event Managerとのすり合わせも完了していない様子なのです。参考ドキュメントもまだまだ貧弱なのですが、以下のサイトにHTMLで記述されたリファレンスがあります。
◇Multilingual Text Engine
　http://developer.apple.com/techpubs/carbon/text/MultilingualTextEngine/multilingualtextengine.html

その他の資料としては、ユニバーサルインターフェースの「MacTextEditor.h」があります（笑）。ところで、私の手元には何故か「MultilingualTextEditor.pdf」というPDFファイルもあります。残念ながら、これをどこから入手したのかは忘れてしまったのですが（多分ADCメンバーサイトだったと思います？）名称がEngineでないことから分かるように、これが現状のAPIを正確に反映しているかどうかは怪しいと思われます。

次はグラフィック関係のアプリケーションに関係する最適化の話しです。まずはMac OS Xの目玉である「Quartz」（Mac OS Xの新しい描画エンジン）についてです。残念ながら、Carbon環境がQuartz APIとどのように関わっているのかは、現状ではまったく分かりません。よって、今のところアプリケーションの描画処理をQuartz APIを使って最適化するといった作業は不可能です。これに関しては今後の展開を待つしかないのですが、デベロッパーにとってそれよりも身近なのは、Mac OS Xから画面表示の仕組みとして取り入れられたダブルバッファ（オフスクリーン描画）にからむ問題です。

この仕組みおかげで、Mac OS Xのウィンドウドラッグでは、「枠」だけでなくウィンドウ画像全体を移動させることができるようになりました。その場合でも、前方ウィンドウで隠されていた後方ウィンドウやデスクトップが「白く抜ける」ことはありません。私は、Next Cubeのデモを最初に見た時に（Jobsが日本で行いました）Nextがこの仕組みをサポートしていることに気づきました。まあ、メモリが128Kしかなく仮想記憶も無かったころの設計思想を引きずったMac OSでは、望むべき事ではなかったというのも事実です。「Macにもあると良いのになぁ〜！」と、その時は思ったのですが、今頃になっていらっしゃると（笑）それはそれで問題が噴出します。

ペイントやドロー系のアプリケーションでは、オブジェクト（ラインとか矩形）を動かしたり引き延ばしたりした時の「画面のちらつき」を防ぐために、オフスクリーン（描画用バッファ）を利用しています。ちらつきは、オブジェクトの消去と描画が短時間で繰り返えされることにより発生します。よって、先んじてオフスクリーン上でオブジェクトの削除と描画を行い、それを瞬時にウィンドウ上へコピーします。この方法により、ちらつきは最小限に押さえられますが、Mc OS Xではそうした手間を掛けなくても、OSが用意したオフスクリーンを利用してウィンドウ描画が行われます。この仕組みが前提ならば、デベロッパーは自前のオフスクリーンを用いている箇所を劇的に減らすことができます。最大の効果はオフスクリーン用のメモリを節約できることです。

逆に今のままだと、自前オフスクリーンからOSオフスクリーンへ、そして最後にはウィンドウへと、画像のコピーが一回余分に起こり、パフォーマンスを悪くするこになりかねません。ただ、この仕組みの無いMac OS 8/9環境では、ちらつき防止策として自前オフスクリーンを使い続ける必要があります。Mac OS Xに特化したアプリケーションでないかぎりは、たとえ冗長であっても、自前で用意したオフスクリーンの仕組みは変更できないでしょう。もうひとつの問題点は描画タイミングに関してです。例えば、以下のようなソースコードをMac OS Xで動かすと、いつまでたってもウィンドウ上にDrawPicture()したはずの画像が表示されません。

　　DrawPicture( pict,&drt );
　　while( ! Button() )
　　　　;

オフスクリーンから画面へのコピーはOS側（プロセスマネージャ）の管理で定期的に行われると思われます（多分）。つまりButton()ルーチンを呼んでいるかぎりは、その処理が起こらないわけです。こうした場合には、新しくサポートされたCarbon Event Mnagerの適切なAPIを使う必要があると思われます。私の自作アプリケーションにこうした箇所がどのくらいあるのか調べてみると、これが結構沢山あることがわかり、頭を抱えてしまいました（涙）。

最後は非常に地味な話しですが「Aqua」への対応についてです。Mac OS X DP3ではAquaが表示するコントロール（ボタンやチェックボックス）のサイズがMac OS 8/9のそれとは異なり、同じようなレイアウトでダイアログが表示できないという問題がありました。とりあえずこの問題はDP4では解決されとJobsは威張っていましたが（笑）日本語表示した場合に、Mac OS 8/9のコントロールではちゃんと表示されるが、Mac OS Xでは途中で文字が切れてしまう現象がまだ残っています。我々、太古からのMacintoshデベロッパーは、これとまったく同じ経験を「System 6からSystem 7」への移行時に経験しました。この時はシステムフォントの設計が大きく変更されたのが原因でしたが、System 6とSystem 7の両方でダイアログを綺麗に見せるためのコントロールのレイアウトに非常に苦労した記憶があります。

加えてAquaは、お節介にもコントロールの「背後の影」まで描画してくれます。よって、ダイアログにコントロールを並べる場合には、上下左右のスペースに余裕を持たせる必要があります。また、コントロールはAquaタイプだが、ダイアログの背景はグレーのままといったアンバランスは見栄えが良くありません。そうなってしまっている例としては、Mac OS X DP4に付属している「Fetch」を参考（？）にしてください。ダイアログの背景にMac OS X特有のシマシマ模様が表示されておらず、これではAquaの魅力も半減してしまいます。良い方の例は「Internet Explorer」でしょうか？こちらは、ダイアログを含めて色々な箇所がAqua対応になっています。具体的には、ダイアログにカスタムカラーを設定するのは止め、‘dlgx’リソースをを待たせてアピアランス対応させる作業が必要です。

Mac OS Xの正式版が登場すれば、もっともっと沢山の最適化箇所が判明するでしょう。Mac OS X独自のシートやドッグなどへの対応！フォント、ネットワーク、ファイルアクセスなどの新APIへの書き換え！多種多様な細かなチューニング作業も表面化するでしょう。しかし、そうした苦労は新しい環境をより良い物にするための礎であるとし、なるべく広い心で受け入れようではありませんか（笑）。

さて今回は、ちょっと長くなりましたので、最新の「CarbonLib 1.1a4 SDK」の話しは次回に回すことにいたします。
関連リンクオッティモ