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 ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
