問題タブ [nsimage]

Cocoa アプリケーションに 3 つの NSView があり、それぞれが他のサブビューです。

FirstNSView -> SecondNSView -> ThirdNSView

FirstNSView は、コア グラフィックスを使用して無地の背景塗りつぶしを描画します。

SecondNSView は、他の多くのビューのコンテナー ビューです。

ThirdNSView は、 の次のコードを使用して、フレームに NSImage を描画しますdrawRect。

[img drawAtPoint:NSMakePoint(0, 0) fromRect:NSMakeRect(0, 0, img.size.width, img.size.height) operation:NSCompositeDestinationAtop fraction:1.0];

NSCompositeDestinationAtopの非透明領域のマスクとして画像をほぼ機能させることができるため、使用していますimg。

ただし、の透明な領域はimg、私が期待するように FirstNSView に透けて見えるのではなく、ウィンドウ全体を透明にします。そのようです：

他の複合タイプを試しても、これと同じ問題が発生することに注意してください。

NSViews が「階層化」を意図していないことについて多くのことを読みましたが、それがここに関連しているかどうかはわかりません。これまでは、Core Graphics を使用して NSView と透明なセクションを使用して、「背後」のレイヤーを公開してきました。この問題が発生したのは、この画像を合成しようとした場合のみです。

これがなぜ起こっているのか、そしてそれを解決する可能な方法についての指針をいただければ幸いです。

Cocoa フレームワーク* を使用して、RGBA パレット (パレット エントリあたり 32 ビット) を使用するパレット PNG 画像 (ピクセルあたり 8 ビット)を作成しようとしています。

[NSBitmapImageRep initWithBitmapDataPlanes:…]メソッドの組み合わせをいくつか試しました。に適したビットマップを作成しているようですbitsPerSample:2 bitsPerPixel:8。

ただし、そのようなビットマップを書き込もうとすると、次のよう[NSBitmapImageRep representationUsingType:NSPNGFileType…]になります。

他のビット深度を試すと、1 ピクセルあたり 32 ビット (パレットなし) の画像が得られます。

*) を使用できることはわかっていますlibpngが、それは私が探している答えではありません。

ディスクからロードされた画像から OpenGL テクスチャを作成する Mac OS >= 10.6 用のアプリを作成しています。

まず、画像を NSImage に読み込みます。次に、画像から NSBitmapImageRep を取得し、glTexImage2D を使用してピクセル データをテクスチャに読み込みます。

RGB または RGBA 画像の場合、完全に機能します。RGB の 3 バイト/ピクセル、または RGBA の 4 バイトのいずれかを渡し、4 バイト/ピクセルの RGBA テクスチャを作成できます。

しかし、ARGB バイト順のように見える JPEG 画像 (Canon EOS 50D で撮影、どのようにインポートされたかは不明) をテスターに​​送ってもらいました。

このスレッドで投稿を見つけました: (http://www.cocoabuilder.com/archive/cocoa/12782-coregraphics-over-opengl.html) これは、GL_BGRA のフォーマット パラメータを glTexImage2D に指定し、 GL_UNSIGNED_INT_8_8_8_8_REV.

それは論理的で、うまくいくように思えますが、そうではありません。色の値は異なりますが、それでも間違っています。

ARGB 画像データを新しい RGBA バッファにシャッフルする「スウィズリング」(手動バイトスワッピング) コードを書きましたが、このバイトごとのスウィズリングは大きな画像では遅くなります。

また、この作業を「正しい方法」にする方法も理解したいと思います。

ARGB データを RGBA OpenGL テクスチャにロードするトリックは何ですか?

xxx への現在の呼び出しは次のようになります。

は RGB または RGBA のいずれかです。

私は使用してみました：

私の画像担当者が「アルファファースト」の順序であると報告したとき。

2 番目の質問として、ほとんどのグラフィック カードの「ネイティブ」フォーマットは GL_BGRA であることも読んだので、そのフォーマットでテクスチャを作成すると、テクスチャの描画が高速になります。テクスチャの描画速度は、テクスチャのロード速度よりも重要であるため、事前にデータを BGRA 形式に「スウィズリング」することには価値があります。GL_RGBA の「internalformat」を指定して、OpenGL に BGRA テクスチャを作成するように依頼しようとしましたが、完全に黒い画像になります。ドキュメントの私の解釈では、ソース形式と内部形式が異なる場合、glTexImage2D がデータを読み取るときにデータをバイト スワップすることを期待していますが、代わりに、「内部形式」を指定しようとすると、OpenGL エラー 0x500 (GL_INVALID_ENUM) が発生します。 GL_RGBA. 私は何が欠けていますか？

アプリケーションが連続して画像ファイルをロードすると、メモリを「スラッシングポイント」まで積極的に消費するという問題があります。たとえば、15MBのJPEGファイル（テスト目的で大きなファイルサイズ）を繰り返しロードおよびリリースする次のコードについて考えてみます。

十分な空きシステムメモリがあるため、最初の数日間は高速に動作しますが、最終的には、システムは私が「スラッシングポイント」と呼んでいるところにひざまずきます。ここでは、システムが次のイメージをロードするのに十分なメモリを解放するため、パフォーマンスが低下することになります。さらに、システムがこの占有されているが現在は使用されていないメモリを解放する必要があるため、他のアプリケーションの実行が遅くなります。

私にとって意味のあることは、メモリを割り当ててからシステムに解放させて、Activity Monitorの「RealMem」統計が連続したロード/リリースの反復でギガバイトに向かうのではなく、小さいままになるかどうかです。実際には、この時点で終わることはないかもしれませんが、いつでも必要な実際の常駐メモリが一般的に小さい場合、ActivityMonitorの「RealMem」統計が最終的に他のすべてのアプリケーションを超えるのは奇妙に思えます。当初、これはある種のメモリリークまたはキャッシュの問題だと思っていましたが、アプリケーションでの積極的なメモリ割り当てとシステムでの遅延メモリの解放に関連しているようです（OSにそのポリシーがある場合は、問題はありません。実際、それが機能する方法）。おそらく私は完全に何かが欠けています。

このホギングや積極的ではないメモリ使用量の動作なしに、画像を繰り返しロードするためのより良い方法はありますか？おそらく、アプリケーションのメモリフットプリントを強制的に下げる方法がありますか、または画像が同じオブジェクトまたはメモリ位置にロードされる方法についてより賢くする方法がありますか？私の目標は、画像を読み込んで処理し（サムネイルを取得し、画像形式を変更するなど）、メモリ内で画像を削除してから、もう一度実行することです。これらはすべて、この観察されたメモリの増加なしに行われます。

-

ファローアップ：

よろしくお願いします。NSAutoreleasePoolをラップすると、同じファイルをロードするときの反復的なメモリの増加が解決されます。

ただし、イメージが解放された後（およびNSAutoreleasePoolがドレインされた後）にメモリが増加したままになる問題は解決されません。たとえば、15MBのJPEG画像をロードすると、「Real Mem」メモリは、8MBの定常状態から約25MBにジャンプし、そこにとどまります。（私のアプリケーションには、コピーしたforループのみを呼び出すメソッドへの有線IBActionを持つInterface Builderボタンしかありません）。forループが終了した後（または1つのイメージのみがロードおよびリリースされた場合）、「RealMem」統計は公称アプリケーションレベルのメモリ使用量に戻ると予想されます。

NSImage機能を呼び出すときに、バックグラウンドで他のものもロードできるのは合理的であるように思われます。これにより、メモリが増加する可能性があります。ただし、サイズの異なる画像（15MB、30MB、50MBなど）は、アプリケーションのメモリを比例的に増加させるため、そのような割り当て以上のものであると私は信じています。

さらに、別々の画像を連続してロードしようとすると（たとえば、15MBjpeg-1.jpg、15MBjpeg-2.jpgなど）、ロードされる新しい画像ごとにメモリが合成されることがあります。たとえば、2つのイメージが連続してロードされた場合、ロード/リリース後のアプリケーションの「Real Mem」メモリ使用量は約50MBになり、私の観察によれば、減少することはありません。この動作は、後続のイメージをロードするときにも継続するため、アプリケーションは、いくつかの大きなイメージをロードした後、数百MBの「RealMem」メモリ使用量に忍び寄ることができます。

興味深いことに、同じ画像を何度もリロードしても、定常状態のメモリは増加しません。これは、進行中のある種のキャッシュを示していますか？繰り返しになりますが、私の目標は、このメモリの増加なしに、いくつかの異なる画像ファイルをバッチ処理することです。前もって感謝します。

ああ、私はヒープショット分析の記事ATMを調べていますが、少なくとも進捗状況を投稿して、他の入力があるかどうかを確認したいと思いました。

-

フォローアップ＃2

素晴らしい記事をありがとう。テストプログラムでInstrumentsAllocationsを実行しましたが、ヒープの増加は見つかりませんでした。参照されているブログ投稿と同様に、私のアプローチは、1）Interface Builderインターフェイスの[画像の読み込みと解放]ボタン（読み込み/解放動作を呼び出す）をクリックし、2）[ヒープのマーク]を数秒ごとに数回クリックすることでした。 Instruments Allocationsで、3）1）と2）を繰り返します。

このアプローチを使用すると、ヒープショットは時間の経過とともにヒープ成長列に0バイトを一貫して報告しました（15秒間5秒ごとに3クリック）。これは、ベースラインヒープショットから追加のメモリが割り当てられていないことを意味します。さらに、[統計]ペインには、[画像の読み込みと解放]ボタンをクリックするたびに13.25MBのMallocがありますが、ライブバイトは0バイトであり、完全に解放されていることを意味します。[画像の読み込みと解放]ボタンを3回クリックすると、画像の全体のバイト数は39.75MB（3 * 13.25MB）と報告されます。これは、39.75MBが割り当てられたが、ライブバイト数が0であるため完全に解放されたことを意味します。割り当てグラフ非常に迅速な操作であるため、すぐに急上昇し、すぐに元に戻ります。メモリの定常状態での使用にリークや成長がないことは、すべて理にかなっているようです。

しかし、「Real Mem」の統計がまだ高い場合はどうすればよいですか？ActivityMonitorはメモリの問題をデバッグするための標準ではないことを私は知っています。しかし、プログラムを閉じるまで「Real Mem」は高いままで、その後「Real Mem」はすべて「無料」カテゴリに戻ります。これは、私にとって奇妙なことです。

同じ方法でコードを複製するだけで、2つの画像（15MBjpeg-1.jpg、15MBjpeg-2.jpg）でこの同じアプローチをテストしましたが、ヒープの増加は見られませんでした。明らかに、より多くの割り当てが行われ、リリースされました。ただし、現在、「Real Mem」は、1つのイメージのみをロードおよびリリースする場合の約2倍の増加になります。また、テストプログラムの定常状態では減少しません。

さらに私にできることはありますか？試してみたい人のための単一の画像のロード/リリースのテストコードは次のとおりです（IBボタンをopenFilesに接続するだけです）。

読んでくれてありがとう。:)

-

フォローアップ＃3

bbum、いいえガベージコレクションを有効にしていません（プロジェクト設定でGCがサポートされていませんに設定されています）。InstrumentsAllocationsのvmmapとVMTrackerバーを使用してメモリを調査しました。vmmapと同じ情報を報告するため、VMInstrumentsと言ったときにVMTrackerデータを意味していると思いました。[画像の読み込みと解放]ボタンを使用して単一の画像を開いた後、いくつかの重要なメモリ数には次のものが含まれます（VMトラッカーから）。

Type         %ofRes  ResSize  VirtSize Res%  %AllDirty  DirtySize
__TEXT       38%     33.84MB  80.45MB  42%   0%         0Bytes
*Dirty*     32%     28.23MB  114.99MB 24%   100%       17.11MB
MALLOC_LARGE 14%     13.25MB  13.25MB  100%  0%         4KB
Carbon       11%     9.86MB   9.86MB   100%  20%        3.46MB
VM_ALLOCATE  9%      8.43MB   48.17MB  18%   49%        8.43MB
...

興味深いことに、単一のイメージの後続のロード/リリースにより、 DirtyおよびVM_ALLOCATEタイプの「ResidentSize」が約0.3MB増加し、これらのタイプの「DirtySize」も時間の経過とともに増加します。（VM_ALLOCATEはDirtyのサブセットのようです）。他のタイプは、その後のロード/リリースで変更されるようには見えません。

このデータから何を取り除くべきか、またはプログラムにメモリを解放させるためにどのように使用できるのか、正確にはわかりません。VM_ALLOCATEタイプは解放されていないチャンクである可能性がありますが、それは単なる推測です。基盤となるNSImageinit実装の一部がイメージファイルのキャッシュを保存し、それを解放しない可能性はありますか？繰り返しになりますが、前述のように、同じイメージファイルの後続の各ロード/リリースは、最初のロード/リリースと比較して、リソース（CPU、ディスクグラインドなど）と実時間をほとんど消費しません。前もって感謝します。

NSTableViewで画像を表示したいのですが、ぼやけて見えます。

別のウィンドウで、NSButton を使用して表示すると、OK です。

NSTableView に収まるように画像をスケーリングしようとしましたが、まだぼやけています。理由は誰にもわかりますか?

[編集] それを解決する方法を見つけました: NSImageCell に境界線を追加します。デフォルトの境界線はなしです。どうしてか分かりません。

複数の子コントロールを含む NSView があります。[childControl setHidden:TRUE] を呼び出すことができることはわかっていますが、子コントロールのメッセージ「drawRect:」をブロックできるかどうか疑問に思っていました。

NSView で [super drawRect:NSZeroRect] を呼び出さなくても、子コントロールには影響しないことに気付きました。私の質問は、子コントロールの drawRect メッセージを呼び出すのは誰ですか? そして、それをブロックする方法があれば。

ありがとう、ホセ。

NSImage からのデータを使用して wx.MemoryDC を構築していますが、結果のコードは非常に遅くなります。TIFFRepresentation -> ImageFromStreamステップは、物事を遅くするものだと私には思えます。この手順 (このすべてのストリーミング) を回避し、NSImage データから直接 MemoryDC を初期化する方法はありますか? サンプルコードは次のとおりです。

内にあるカスタムNSViewがNSScrollViewありNSSplitViewます。カスタムビューは、次の図面コードを使用します。

私はすべての異なるタイプを試しoperationましたが、画像はまだ他の半分の上に描かれてNSSplitViewいます：

…下に描画する代わりにNSScrollView。これは、すべてではなくすべてを描画することと関係があると思いますがdirtyRect、画像描画コードを編集して、にある部分のみを描画する方法がわかりませんdirtyRect。 どうすればそれが上に描画されないようにするか、このNSImageのダーティレクを描画するだけですか？

情報を表示する NSImage を含むメニューがあり、更新されたときに新しい (更新された) イメージをフェードインさせたいと思います。iPhone では簡単ですが、OS X でこれは可能ですか?

NSViewサブビューのdrawRectを使用して、テクスチャアトラスをアプリにロードしています。

これは正常に機能しますが、テクスチャアトラス全体を表示します。画像の特定の部分にゾーンインするにはどうすればよいですか？画像は1800x1200ピクセル、各画像は180x250ピクセルであるため、画像1はx = 0、y = 0、w = 180、h = 250、2つはx = 180、y = 0、w = 180、h=250になります。 、 等々。

上記のx、y、w、hを変更してみましたが、出力は黒い画像にすぎません。どんな助けでもいただければ幸いです。

編集：これが正しいかどうかはわかりませんが、解決しました：

ファイルを1100x1100に変更しました（これはソリューションには影響しませんが、回答に反映されるため、メモしたいと思います。次に、画像の間違った領域（x、y）をターゲットにして、間違ったサイズをターゲット。新しいコードは次のようになります。

これを達成するための別の方法がある場合は、それを見てみたいと思います。ありがとう。