0

または...「いつpluginWindowMac::InvalidateWindow()を呼び出すか」?

申し訳ありません。ここで簡潔にするのは難しいです。これはかなり特殊なテスト ケースです。

Firefox、Safari、Chrome、および IE で NPAPI プラグイン (現在 Firebreath に適合) をテストしています。Windows と OS X の両方でプラグインをテストしています。

すべてのレンダリングに OpenGL を使用するビデオ プレーヤーです。そのため、OS X では CAOpenGLLayer 派生クラスを使用し、Firefox と Chrome の両方で使用される Invalidating Core Animation モデルをサポートしています。

プラグインは、OS X 10.6 と 10.7 の両方で奇妙な「更新」の問題が見られる OS X 上の Chrome (v26.0.1410.65) を除いて、すべての場合と両方のプラットフォームで正常に動作しています。

Chrome が合成レイヤーをどこかにダブル バッファリングしているかのようです。これは、OpenGL 経由で描画されたフレームよりも常に 1 つの「フレーム」です。これは、各描画呼び出しに番号を付け、その番号を OpenGL レンダリングに描画し、NSLog を介してログに記録することで証明しました。画面に表示されるのは、ログに記録された描画コールバックの 1 つです (この時点ではビデオをレンダリングしていません - 一時停止しています)。

特定のキーボード イベントを使用して pluginWindowMac::InvalidateWindow() への追加の呼び出しをトリガーすることにより、画面上の内容を最後にレンダリングされたものと同期させる外部無効化を強制できますが、次の描画呼び出しで再び同期が失われます。 (レイヤー setNeedsDisplay によってトリガーされます)。

現在、各描画コールバックの最後に pluginWindowMac::InvalidateWindow() を呼び出しています。つまり、レイヤーの最後に「drawInCGLContext()」を呼び出します。これは、それを行う唯一の論理的な場所のようです。しかし、Chromeではこれが機能していないのではないかと疑い始めていますか? 明らかに呼び出しは機能します - キーボードが InvalidateWindow をトリガーしたことで証明されていますが、drawInCGLContext 内からは機能しないのではないでしょうか?

プラグインは、Firefox (Invalidating Core Animation を使用する他のブラウザー) で正常に動作しています。しかし、それは単に動作中の pluginWindowMac::InvalidateWindow() に依存していないのでしょうか?

Chrome でこの問題につまずいた人はいますか? 発見された回避策はありますか?私が今考えることができるのは、追加の無効化をトリガーするある種のタイマー駆動型イベントです。

4

0 に答える 0