15

私はノード キャンバスで TJ にバグを報告してきました。彼が作成および管理しているノード モジュールのフォークで作業しているコードの高速化についてです。

Canvas.toBuffer() がパイプライン リソースを強制終了していることがわかり、png バッファー/メディア URL を経由せずに Canvas から Image に単純に変換する代替手段を作成しました。問題は、cairo が不可解な野獣であり、マザー v8 によって GC されないように、ノード モジュール内に割り当てられたメモリに関する追加レベルの懸念があることです。V8 データにアクセスするために必要なすべての関数に、適切な HandleScopes を追加しました。

私は自分の Mac セットアップ (6.18) で Canvas.loadImage(image) メソッドを何千回もテストすることができました。また、同じバージョンのノードを実行している ubuntu/運用サーバーでスタンドアロン テストを行うこともできました。しかし、コードがバックグラウンド プロセス/サーバーとして実行され、Gearman によって調整されると、「興味深い」メモリ/セグメンテーション違反が発生します。

さらに、ヘッダー ファイル内でインライン化されていない node-canvas で定義されたクラスのメソッドを呼び出すのに問題があります。副次的な質問として、他のノード モジュールが依存できる共通のネイティブ ソース コード パッケージを作成する最善の方法は何ですか?

問題を再現して、gdb、node_g、およびシンボルとデバッグ フラグで構築されたすべてのノード モジュールで実行してみました。しかし、スタック トレースを取得できるソース以外のライブラリでエラーが発生します。

参考までに、ここで loadImageData を呼び出します。さまざまな条件下でローカルで実行されている間、フレーム サーバー内に慎重に押し込められた本番環境では、セグメンテーション違反が発生しているように見えます (昨日はサーバー コードを gdb node_g しようとしましたが、フレーム サーバーはギアマンによってキックオフされます... TL;DR は根本原因のスタック トレースを取得しませんでした)

https://github.com/victusfate/node-canvas/blob/master/src/Canvas.cc#L497

Handle<Value>
 Canvas::LoadImage(const Arguments &args) {
   HandleScope scope;
   LogStream mout(LOG_DEBUG,"node-canvas.paint.ccode.Canvas.LoadImage");    
   mout << "Canvas::LoadImage top " << LogStream::endl;

   Canvas *canvas = ObjectWrap::Unwrap<Canvas>(args.This());
   if (args.Length() < 1) {
     mout << "Canvas::LoadImage Error requires one argument of Image type " << LogStream::endl;
     return ThrowException(Exception::TypeError(String::New("Canvas::LoadImage requires one argument of Image type")));
   }

   Local<Object> obj = args[0]->ToObject();
   Image *img = ObjectWrap::Unwrap<Image>(obj);
   canvas->loadImageData(img);
   return Undefined();
}  

void Canvas::loadImageData(Image *img) {
  LogStream mout(LOG_DEBUG,"node-canvas.paint.ccode.Canvas.loadImageData");    
  if (this->isPDF()) {
    mout << "Canvas::loadImageData pdf canvas type " << LogStream::endl;
    cairo_surface_finish(this->surface());
    closure_t *closure = (closure_t *) this->closure();

    int w = cairo_image_surface_get_width(this->surface());
    int h = cairo_image_surface_get_height(this->surface());

    img->loadFromDataBuffer(closure->data,w,h);
    mout << "Canvas::loadImageData pdf type, finished loading image" << LogStream::endl;
  }
  else {
    mout << "Canvas::loadImageData data canvas type " << LogStream::endl;
    cairo_surface_flush(this->surface());
    int w = cairo_image_surface_get_width(this->surface());
    int h = cairo_image_surface_get_height(this->surface());

    img->loadFromDataBuffer(cairo_image_surface_get_data(this->surface()),w,h);
    mout << "Canvas::loadImageData image type, finished loading image" << LogStream::endl;
  }   
}

Image の現在のメソッドは次のようになります (コメントアウトされたログ情報を削除しました) https://github.com/victusfate/node-canvas/blob/master/src/Image.cc#L240

/*
 * load from data buffer width*height*4 bytes
 */
cairo_status_t
Image::loadFromDataBuffer(uint8_t *buf, int width, int height) {
  this->clearData();
  int stride = cairo_format_stride_for_width (CAIRO_FORMAT_ARGB32, width); // 4*width + ?
  this->_surface = cairo_image_surface_create_for_data(buf,CAIRO_FORMAT_ARGB32,width,height,stride);
  this->data_mode = DATA_IMAGE;
  this->loaded();
  cairo_status_t status = cairo_surface_status(_surface);
  if (status) return status;
  return CAIRO_STATUS_SUCCESS;
}

ヘルプ、プロのヒント、支援、励ましの言葉をいただければ幸いです。

元はGoogleグループから

4

2 に答える 2

1

さらに、ヘッダー ファイル内でインライン化されていない node-canvas で定義されたクラスのメソッドを呼び出すのに問題があります。副次的な質問として、他のノード モジュールが依存できる共通のネイティブ ソース コード パッケージを作成する最善の方法は何ですか?

ステージング環境で発生していたメモリの問題/セグメント障害に対する答えはありません。ネイティブノードモジュールを使用して再利用可能なライブラリを構築するための答えがあります。

すべての独立したネイティブ ノード モジュールに git サブモジュールを使用し、wscript または binding.gyp ファイルごとに条件付きプリプロセッサ定義を追加して、共有オブジェクト .node モジュールを生成するかどうかを指定しました。

update または、一意の init 関数名または名前空間でモジュールの初期化呼び出しを囲むことができます (この設定に移動しました)。

さらに、この新しいパッケージを使用して、コード セクションのデバッグや書き直しを支援します (いくつかのリモート ライブラリの利用をデバッグするのにあまり時間をかけられません)。

wscript または binding.gyp で

  flags = ['-D_NAME_NODE_MODULE', '-O3', '-Wall', '-D_FILE_OFFSET_BITS=64', '-D_LARGEFILE_SOURCE', '-msse2']

次に、初期化ファイルで

#ifdef _NAME_NODE_MODULE

extern "C" {
  static void init(Handle<Object> target) {
    HandleScope scope;
    NODE_SET_METHOD(target, "someFunction", someFunction);
  }

  NODE_MODULE(moduleName, init);
}

#endif

このようにして、フラグが設定されている場合にのみ、ノードのネイティブ モジュールが追加されます。それ以外の場合は、通常どおりにリンクできます (別のノード モジュールのように)。

于 2012-06-20T22:09:38.080 に答える
1

とった！

私は今日、cairomm を使用する別のライブラリに取り組んでおり、データ バッファーから作成されたサーフェスでは、サーフェスが存在する限り、それらのバッファーが存続する必要があることを発見しました。

http://www.cairographics.org/manual/cairo-Image-Surfaces.html#cairo-image-surface-create-for-data

「提供されたピクセル データのイメージ サーフェスを作成します。cairo_surface_t が破棄されるか、サーフェスで cairo_surface_finish() が呼び出されるまで、出力バッファを保持する必要があります。データの初期コンテンツは初期イメージ コンテンツとして使用されます。明示的に指定する必要があります。クリアしたい場合は、たとえば cairo_rectangle() と cairo_fill() を使用して、バッファをクリアしてください。」

一時バッファーから作成されたサーフェスを導入しました。

node-canvas fork での簡単な解決策:

_data と呼ばれるメンバー変数があり、ローカルに割り当てられたデータ バッファーを割り当てることができます。これは、cairo サーフェスが存在する限り存続します。

解決策:

バッファをサーフェスにコピーする一般的な方法は、バッファから一時的なサーフェスを作成し、その一時的なサーフェスから割り当てられたサーフェスに描画して、cairo に自身のメモリを管理させることです。

実装するcairoへのc APIを使用すると、次のようになります。

cairo_surface_t *pTmp = cairo_image_surface_create_for_data (
   data
 , CAIRO_FORMAT_ARGB32
 , width
 , height
 , cairo_format_stride_for_width(CAIRO_FORMAT_ARGB32, width));

_surface = cairo_image_surface_create ( CAIRO_FORMAT_ARGB32
 , width
 , height);

cairo_t *cr = cairo_create (_surface);
cairo_set_source_surface (cr, pTmp, x, y);
cairo_paint (cr);
于 2012-07-25T20:06:27.120 に答える