問題タブ [gdkpixbuf]

私はC++ でGdk::Pixbuf画像を表示するためにa を使用しています:Gdk::Cairo

この画像は白黒で、輝度が特定のしきい値を超えているいくつかのピクセルを取り出す必要があります。そのために、それらのピクセルに色を付けたいと思います。

まず、Pixbuf 画像の特定のピクセルの輝度を取得する方法がわかりません (Web で見つけることもできません)。

第二に、長さ 1 の線を描画する以外に、ピクセルを描画する別の方法が見つかりません (これは一種の醜い解決策です)。

これについて私を助けてもらえますか？可能であれば、ライブラリの変更は避けたい...

ありがとうございました

フォルダ アイコンをテクスチャとして読み込もうとしています。私は今ほとんどすべてを試しましたが、何らかの理由で機能させることができません

このスレッドはまさに私が探しているものだと思いますが、高度すぎます。とりあえずシンプルにしたい。

何らかの理由で、これを機能させたり翻訳したりできません。

これは私が最終的に得たコードです。今何をすべきかわからない。

GTK+ 2 アプリケーションを GTK+ 3
に移植しています。画像の一部を切り取る機能があります -

pb関数に渡される pixbuf です。scaled_pb が返されます。
だから私の質問は、GTK3 で pb.subpixbuf に代わるものは何ですか? 私のアプリは現在実行されておらず、Pixbuf オブジェクトに subpixbuf プロパティがないことを示しています。

前もって感謝します。

P/Invoke を使用して、いくつかの C++ DLL からアンマネージ関数を呼び出すコードに取り組んでいます。アプリケーションを 32 ビットまたは 64 ビットとしてビルドできるようにしたいと考えています。

現在、x86 としてのみ動作します。

参照されている C++ DLL のそれぞれの 32 ビットと 64 ビットのコピーがあり、次のコードを使用して、アプリが x86 または x64 としてビルドされているかどうかに応じて DllDirectory を変更しています (/lib/x64 は 64 ビット DLL、/lib/ を保持します)。 x86 は 32 ビットのものを保持します):

残りのアンマネージ C++ 関数は次のように定義されています。

これらの関数を実際に使用するコードは次のようになります。

前述したように、アプリケーションをローカル マシン (Windows 7 x64) で x86 として実行すると、すべて正常に動作します。ただし、x64 アプリケーションとしてコンパイルすると、gdk_pixbuf_save() の呼び出しで「AccessViolationException」が発生します。

何か案は？私は相互運用コードに比較的慣れていませんが、IntPtr 変数がアンマネージ コードとの間で送受信される方法に関係があると思いますか? しかし、x86 と x64 ではなぜ違うのでしょうか?

C# と P/Invoke を使用して GDK ライブラリにアクセスしています。私の目標は、一連の SVG ファイルをラスター イメージ (具体的には png) に変換することであり、GDK ライブラリを使用することが最も信頼性が高く正確なようです。

Gnome/Cairo のドキュメントを読んだ後、これを達成するための 2 つの基本的なアプローチを見つけました。これらのアプローチの 1 つは非推奨の関数を使用し、もう 1 つは使用しません。

最初のアプローチは推奨されていませんが、間違いなくより単純でわかりやすいもので、基本的には次のようになります。

非推奨ではない2 番目の方法では、Cairo サーフェスをセットアップしてレンダリングし、ファイルに保存します。基本的には次のようになります。

これらのアプローチはどちらも機能しているようです-正しいラスター画像出力を生成します（ただし、一連の操作を並行して実行しようとすると、「カイロの方法」にはいくつかのバグがあります-メモリが不足してしまいます）。

私の質問は次のとおりです。古い/非推奨の方法 ( rsvg_pixbuf_from_file_at_size)が新しい/Cairo の方法よりも著しく速いのはなぜですか? 私のテストでは、最初のアプローチが全面的に高速であることが示されています (1 つのファイル/複数のファイル、標準の C# ForEach/Parallel.ForEach)。

たとえば、16 個の入力ファイル (出力サイズが 6000x4200) で並列処理がない場合、最初のアプローチは ~2:15.89 秒かかります。2 番目のアプローチでは、約 2:37.95 かかります。並列処理 (Parallel.Foreach が私の P/Invoke コードを呼び出します) でも、結果は似MaxDegreesOfParallelismています。デフォルトに設定すると、非推奨のアプローチで 30.7 秒、Cairo アプローチで 36.95 秒かかります。

Cairo もかなり多くのメモリを使用しているようです。さらに、Cairo は変換ごとにより多くのリソースを使用するだけでなく、RAM のすべてを使用しないようにする方法も知らないようです。たとえば、入力ファイルの数を (16 から) 720 に増やし、Parallel.ForEach ループを使用すると、空き RAM が 0 MB になり、システムが停止します (最終的に、デバッグ プロセスは終了します)。 、そして私のシステムは戻ってきます...しかし、それは1分ほどロックアップします)。

私の質問に対する簡単な答えは、非推奨のアプローチを使用することですが、なぜ非推奨なのですか? カイロのアプローチは、何らかの点で優れていますか?

誰かが私のコードをもっと見たい場合は、お知らせください。追加します。投稿したコードを関連するビット (実際の P/Invoke コードであり、それを呼び出す C# コードではありません) だけに切り詰めようとしました。