On Mon, Sep 27, 2004 at 08:59:33AM +0200, Dirk Rydvan wrote:
> We want use FVWM instead KDE to improve performance - so far so good.
>
> But there are a performance problem on FVWM.
> We have seen this only on a poor java application. ( poor but very
> important ... )
>
> If I change the Desktop - the application will redrawed and this takes a
> while.
> A few seconds are necessary to show the complete window item.
> (it takes more time than KDE)
>
> If I change only the Page in the Desktop - the application will showed
> very fast.
> ( better than KDE)
> And the +bs option (backing store) works only between the Pages in the
> Desktop.
That is because there are two basic ways of managing desks in
window managers. Fvwm and some other window managers unmap
windows when they are not on the active desk. Backing store can
not work here because there is no mapped window. Other window
managers (kwm, I guess) create a desktop window that is as big as
the screen for each desktop. The current desk's window is raised
to the top, and no window is ever unmapped - backing store has a
chance to work.
> A easy way to solve the Problem is, to create only one Desktop and
> seperate this
> in 10 Pages.
> But a have a Problem - we need a Label for each Workspace (Page).
> That is not possible with FvwmPager. FvwmPager provides only Labels for
> Desktops.
The root of the problem is that the application takes too long to
redraw. If possible at all, You should revisit the code and fix
the largest performance leaks.
But - with a bit of scripting you can circumvent the problem
within fvwm (2.4.x):
*FvwmEvent: Cmd
*FvwmEvent: new_desk NewDeskFunc
AddToFunc NewDeskFunc
+ i Piperead "if [ $[desk.n] = 0 ]; then echo ShowMe; else echo HideMe; fi
AddToFunc ShowMe
+ I All (appname) ThisWindow (!currentpage) move w+1000 w+1000
AddToFunc HideMe
+ I All (appname) ThisWindow (currentpage) move w-1000 w-1000
Style appname Sticky
(replace appname with a pattern that matches all windows of the
application). Then add FvwmEvent to your StartFunction. It's
important that the application window is sticky - Otherwise it
will get unmapped when the desk is switched. whenever you switch
to a desk other than zero, the application is moved to a parking
position 10 pages up and to the left of its current position.
Switching to desk 0 brings it back.
This solution fails if the user unsticks the window, or if a desk
has multiple pages. The latter problem can be fixed by replacing
the "Thiswindow (...)" call by a PipeRead script.
With 2.5.1 or later, the script can be written in a mor robust
fashion, avoiding the multiple-page problem altogether:
*FvwmEvent: Cmd
*FvwmEvent: new_desk NewDeskFunc
AddToFunc NewDeskFunc
+ i Piperead "if [ $[desk.n] = 0 ]; then echo ShowMe; else echo HideMe; fi
AddToFunc ShowMe
+ I All (*macs*) ThisWindow (State 25) move w-1000 w-1000
+ I All (*macs*) State 25 off
AddToFunc HideMe
+ I All (*macs*) ThisWindow (!State 25) move w+1000 w+1000
+ I All (*macs*) State 25 on
"25" is the number of a user defined bit (0 to 31). The actual
value is not important, but it must not collide with other bit
numbers in the configuration file.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt_at_gmx.de
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
- application/pgp-signature attachment: stored
Received on Tue Sep 28 2004 - 06:11:20 BST