Subject: another solution for frame layout

From: Dominik Vogt <[email-masked]>
Date: Wed, 13 Mar 2002 00:46:34 +0100

(started a new thread so that I don't have to quote tons of old
mails ;-)

Here is a simple solution to all problems with flickering that
does not even require all these additional windows: Draw behind
the scenes.

 - Create a sub window of the frame that has background_pixmap set
   to None.
 - Stack it above all the decorative windows, but below the title
   bar windows and the parent.
 - Before an animation step, resize it to a size that covers both,
   the old and new size of the frame window.
 - Map it.  Because of the "None" background pixmap, it just gets
   the contents of the windows that it covered.
 - Draw the new border and title windows behind that 'invisible'
   window (as background pixmaps).
 - Give the 'invisible' window UnmapGravity and set the proper
   gravities of the decoration windows.
 - Resize the frame.  Said window is automagically unmapped and
   uncovers the windows below it.
 - The X server automatically draws the now exposed parts with the
   background pixmaps of these windows.

The only unwanted side effect is that the X server draws the
complete border in each step, although it does that without any
additional client/server communication.  Probably not much of a
problem because it already does that right now for half of the
border.  All this is invisible because it just repaints the same
pixels that are already there.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Wed, 13 Mar 2002 16:24:59 +0000

>  - Create a sub window of the frame that has background_pixmap set

And BackingStore: NotUseful to save server memory

>    window (as background pixmaps).

Is the title window above or below the magic window?

>    background pixmaps of these windows.

Sounds great, I never knew about UnmapGravity.

> additional client/server communication.

It shouldn't be a problem at all, it should be just tiling from the 
backing pixmap so it should be done by the graphics hardware.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 13 Mar 2002 23:44:22 +0100

> Is the title window above or below the magic window?

I'm not sure about that yet.

> backing pixmap so it should be done by the graphics hardware.

Unfortunately that approach doesn't remove the need for additional
windows to draw the reliefs - at least for windows with a
background pixmap set.  We still can't draw into the pixmap
itself, and there is no general way to make one big window with
transparent holes that show the background pixmap (at least if we
don't want to draw on the foreground of the windows).  I'm still
digging through the documentation of all that gravity stuff.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 15 Mar 2002 14:59:13 +0100

So, here is what I'm going to implement.  It's a hybrid of the
various solutions proposed so far.

 - Gets rid of the decor_w.
 - Does not need any additional windows for each frame.
 - Works the same with and without background pixmaps in the
   border.
 - The border is drawn into the eight handle windows.  They have
   to be mapped all the time (slight performance penalty for
   "NoHandles" windows).
 - Windows that have no background pixmap and no bevels can be
   resized without any drawing directives.
 - For each resizing step, the X server repaints the whole border.
   This is invisible to the user.  (performance penalty)
 - Resizing the frame does not flicker at all.
 - For each handle window that has to be redrawn by the client,
   a pixmap has to be created and destroyed.  Even if its size
   keeps constant during several animation steps it can not be
   recycled because according to the X documentation, the X server
   *does* keep a copy of the pixmap but *may* update that copy if
   anything is drawn in the original pixmap. (performance penalty)
 - The drawing commands have to be repeated for each of the
   pixmaps being updated. (performance penalty)
 - In total, fvwm needs only four additional windows, regardless
   of the number of managed client windows.
 - Dramatically reduces the number of Expose events sent by the
   server.  Actually, if we rewrite the title bar code to use the
   same mechanisms, fvwm doesn't need to select Expose events on
   the managed windows at all.
 
Now the details:
----------------

Preparations:

 - The eight handles are created InputOutput children of the frame
   window.
 - The border is drawn into pixmaps that are set as the background
   pixmap of the handles.

Resizing:

 - The existing window borders are obscured by four windows that
   have a 'None' background pixmap and UnmapGravity.  They may be
   created specifically for that purpose or be created only once
   and reparented to the root window until they are needed.  No
   events have to be selected and they may even be
   override_redirect.
 - For a tiled background, the pixmap is filled with
   XFillRectangle() using the background pixmap as the fill tile
   of the used GC.  This is the most expensive operation for
   redrawing.
 - The reliefs are drawn over the tiled pixmap.  Since the bevels
   are drawn into the corner handles, the side handles can be
   as small as the background pixmap.
 - The backgrounds of the handle windows are set using the
   new background pixmaps (if necessary).
 - The frame is resized.  This automatically unmaps the obscuring
   window.  The border windows are refreshed automatically by the
   X server without any client/server communication.  They do not
   even need to select Expose events.

Stacking order (top to bottom):

  Title/button windows
  Obscuring windows
  Corner windows
  Side windows
  Parent

Notes:

  The top, top/left and left handles rarely have to be redrawn by
  the client at all.  This is only necessary when the size of the
  top/left handle changes and either the bevels or a pixmap
  background is used.

I'm on the job.

Bye

Dominik ^_^  ^_^