0

ネストされた X ウィンドウがいくつかあります。たとえば、スクロール可能なウィンドウ内のスクロール可能なウィンドウです (以下の例を参照)。このような場合、メイン ウィンドウには、(少なくとも) 主要なスクロール バーと、それらが制御する (主要な) 描画領域が含まれます。この描画領域には、(少なくとも) スクロール可能なウィンドウ バッチ (スクロール バーと小さな描画領域を含む (マイナー) メイン ウィンドウ) が含まれます。

XCopyArea を使用してプロセスを高速化し、有効なコンテンツを移動し、新しく表示されたコンテンツに対して実際の再描画ルーチンを呼び出すため、内側の描画領域のライブ スクロール中に再描画手順が台無しになります。これは、内側の描画バッチが単独である場合は問題なく動作しますが、別の描画バッチ内にネストされている場合、問題が発生します - 内部の scrolling-batck が部分的に表示されている (つまり、主要な描画領域がスクロールされている) 場合、新しく表示されたコンテンツの再描画は主要な描画から切り取られます。実際に再描画されることはありませんが、再描画されると見なされます。次のスクロールで XCopyArea がこのおそらく再描画された領域を取得すると、実際には空になります。最後に、この空の領域が部分的に表示されている内部スクロール バッチに表示され、空になります。最初の一般的な再描画メッセージで、それらは修正されます。

(私の) 内側の描画領域から実際に見えるもののクリッピング マスクを取得できれば、XCopyArea() 呼び出しと再描画呼び出しを調整して、スクロール バーの移動ごとにすべてのコンテンツを再描画する計画 "B" なしで問題を解決できます。 .

例: Mozilla Firefox 用のプラグインを開発していて、「自分の」ウィンドウの可視領域を表す領域 (つまり、Mozilla システムからプラグイン ビューポートとして渡される領域) を決定する必要がある場合。

4

1 に答える 1

1

それが実際に取得した X Window であり、特定のツールキット (GTK+ など) のウィジェットではない場合は、XGetWindowAttributes 関数呼び出しを使用できます。

これにより、提供された XWindowAttributes 構造体が埋められます。この構造体には、ウィンドウの x 位置と y 位置の整数、幅と高さ、およびその他の有用な情報が含まれています。

しかし実際には、おそらく Netscape から継承された Mozilla プラグイン API、別名 NSAPI を使用していると思います。探している情報を含む構造。使用すべき API の詳細については、http://www.mozilla.org/projects/plugins/を参照してください。

于 2008-09-16T16:34:44.827 に答える