[Xorg] Composite and Background == None windows
keithp at keithp.com
Fri Jul 9 12:25:18 PDT 2004
I'm having trouble getting Background == None windows to work
right with Composite. The problem is that when these windows
are mapped, you get garbage contents for the backing pixmap.
Background == None windows are for two reasons:
1) To avoid flashing a background pixel which will
immediately be replaced by "real" contents.
2) To capture an image of the screen inside the window
I submit that case 1) is a more "legitimate" usage as 2) breaks in the
presense of different visuals in any case. So, it's important to
get case 1) right while still letting case 2) do something
For case 1) (used for menus and window manager frames), it seems
like the right solution is to avoid painting the window at all
until the application has managed to fill it entirely with the
correct content. That would require Damage to be modified to let the
application know when the window was completely painted, probably by
adding a boolean to the damage event to pass that information along.
However, when you create a Damage structure for a window, it is
initialized to the borderClip for that window; if the window is mapped
(and it often is, even for new windows because applications are pretty
quick to create/map menus) then the whole window ends up damaged, even
though it hasn't painted anything yet. I don't see how to fix that --
the new Damage would have no context to know whether the bits in the
window were painted by the application or not.
However, we can easily solve case 2) -- just copy the screen area to the
backing pixmap when the window is mapped. If the compositing manager is
doing anything weird with the windows, you may get strange looking results
though -- any shadows will be painted around the "window", even though
that "window" was filled with bits from the screen underneath it.
I guess the right solution is to implement the trivial fix for 2) and then
work on ICCCM extensions for applications to communicate with the
compositing manager about window painting state. Those extensions are
required to avoid screen artifacts in other cases, so I guess it's not so
bad that we need them for menus as well.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 228 bytes
Desc: not available
More information about the xorg