On Wed, 10 May 2006, Dominik Vogt wrote:
On Wed, May 10, 2006 at 12:17:38AM +0200, Dominik Vogt wrote:
On Tue, May 09, 2006 at 11:25:41PM +0200, Viktor Griph wrote:
On Fri, 5 May 2006, Dominik Vogt wrote:
On Thu, May 04, 2006 at 08:54:25PM +0200, Viktor Griph wrote:
When are the hide windows useful in frame.c? The call to
frame_reparent_hide_windows in frame_create_move_resize_args casue X to
generate extra VisibilityNotify events to clients during capture and
redecoration (bug #3977).
The hide windows are emtpy windows (with a "None" background
pixmap). I introduced them to reduce flickering of the window
decorations when a window is resized, and - more important -
shaded or unshaded.
The problem is that when you resize a window, you can tell X which
border its subwindows should stick to. But you can not tell it
where the subwindows of subwindows should go, and it's not
possible to resize subwindows in the same operation.
Because of this, I use the hide windows to cover some parts of the
decorations, resize the window, redraw the the changed parts of
the decorations windows (using a background pixmap, not using the
foreground), then unmap the hide windows to uncover the changed
decorations. Usually, the hide windows stay "invisible" because
htey have no contents and just show what was below them until they
are covered by something else.
Now I understand the need for them for resize operations.
Would it be possible to narrow down the need for
that function call to some specific case?
I don't see any way but at the expense of flickering decorations
and subwindows, especially with opaque resizing.
Am I right if I say that the hide windows do no good if it is a setup
request and the frame size has not changed? I'm not sure how the initial
mapping is treated, but I believe they do no good for that either. It's
just a little harder to seed that condition from withing the function.
I'm not entirely sure about this, but as far as I remember the
hide windows are resized to cover only the relevant parts of the
window. I.e. if the window size does not change, the hide windows
do not cover anything (I'm not sure if the hide windows are used
at all in that case). There may be some room for optimizing here.
I just checked the code. As far as I can see, the hide windows
just cover the decorations if the window size does not change.
Unless the size calculations are going wrong I can not see why
this causes extra Expose/VisibilityNotify events on the client
window.
Something is wrong with the calculations. I don't have time to check them
now but there seems to be problems with borderless windows and windows
with with no title at top.
You may try to open a FvwmConsole and do
# Move the title to a non-top position
Current WindowStyle TitleAtLeft
# The following works fine i.e. no extra redraw
Style * !Button 0
# This one on the other hand casue a redraw of the top of the console
# compareable to title height
Style * !Button 0
# Now move the title to the right
Current WindowStyle TitleAtRight
# this will cause a redraw of the area where the title last were present.
Style * !Button 0
This may be due to other bugs, but it's the hide windows that casue the
observable effect. Similar, but not equal, effect may be observed if Style
* is replaced by Current WindowStyle. I believe the windows aren't moved
until after they are shown, or that some in other way old information is
used to calculate the size of the hide windows. Also windows with no
borders get hide windows covering the client window. As it stands now I'm
not sure if any of this is related to bug #3977. I've not been able to
reproduce the said flickering with xdvi, nor am I able to reproduce the
events with an xev window. In fact I believe the bug must be due to some
specific configuration.
Actually, if applications like xdvi have a below par redraw
algorithm (i.e. they redraw whenexer they receive an Expose
event), that's the applications' problem and not the problem of
the window manager.
It's true that the application may be behaving badly, but there are
several application that show similar flickering due to the exrtra events
on a redecoration. if it's possible to work around the events with the
window mannager it's a good thing to do, but not at the expense of some
other functionality. Just for reference the thing that annoys me most
about this is the fact that my titleless pager and xbuffy flash whenever
I redecorate (including even disable an already disabled title bar button)
/Viktor
