On Wed, May 10, 2006 at 04:40:19PM +0200, Viktor Griph wrote: > 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.
Actually, the hide_window code does not deal with decoration layout changes; it assumes the decoration sizes on each side of the window are constant in a setup operation. It's just meant to allow smooth resizing and shading. We can live with this specific problem, I guess. > Also windows with no > borders get hide windows covering the client window. Uh, the hide windows get a random size in this case. Instead, they should not be mapped at all. I'll fix this. > 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. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
