私はいくつかのネストされたXウィンドウを持っています - スクロール可能なウィンドウ内のスクロール可能なウィンドウを考えてみましょう（下の例を参照）。そのような場合、メインウィンドウには、（少なくとも）主要なスクロールバーと、それらが制御する（メジャー）描画領域が含まれます。この描画領域には、少なくともスクロール可能なウィンドウバッチ、つまりスクロールバーとマイナーな描画領域を含む（マイナー）メインウィンドウが含まれています。X Windows/LinuxでWindowsの可視領域を特定する方法は？
内部描画領域のライブスクロールでは、XCopyAreaを使用してプロセスを高速化し、有効なコンテンツを移動して新しく表示されたコンテンツのみの実際の再描画ルーチンを呼び出すため、再描画処理がうまくいきません。これは内部の描画バッチがそれ自身では機能しますが、別の内部で入れ子になったときに問題が発生します - 内側のスクロールバットが部分的に表示されているとき（つまり、主要描画領域がスクロールされているとき）実際に再描画されることはありませんが、そうであると考えられます。次のスクロール時に、XCopyAreaは、このように再描画された領域を取得します。実際には空です。最後に、この空の領域は、部分的に目に見える内側のスクロール・バッチに現れ、空です。最初の一般的な再描画メッセージでは、それらは修正されています。
実際に（私の）内側の描画領域から表示されるクリップマスクを取得できる場合は、XCopyArea（）呼び出しを調整して呼び出しを再描画し、すべての内容を再描画するプラン "B"なしで問題を解決できます。各スクロールバーの動き。
例：Mozilla Firefoxのプラグインを開発し、「my」ウィンドウの可視領域を表す領域、つまりMozillaシステムからプラグインビューポートとして渡される領域を特定する必要があります。
はい、NSAPI呼び出しから渡されたウィンドウですが、プラグインが実際に動作する別の（子プロセス）プロセスで使用されます。 XGetWindowAttributesは情報を提供しますが、ウィンドウが覆われているか、最も重要なのかがスクロールダウンされ、部分的に表示されるかどうかはわかりません。 – theJonan
これはX Window System、または "X Windows"ではなく、ただのXです。 – postfuturist