On Sun, Mar 17, 2002 at 02:38:05AM -0800, John Smith wrote:
> Okay, so now that I'm using 2.4.6, I definitely see opaque/rubber band window
> moving faster than the previous release. As a user with a cluttered desktop,
> sometimes opaque window moving slows down quite a bit (but still a lot better
> than other WMs I must say). However, the fastest opaque moving I have seen
> >from any window manager is by far in mwm.
In general, mwm will probably always be faster because it has
almost no features. Consider what fvwm does when moving a window:
- Move the window
- Handle keyboard events.
- Handle lots of funny modifier key combinations.
- Use the SnapGrid
- Uses SnapAttraction
- Uses EdgeResistance
- Handles paging
Some of this requires communication with the X server which is the
main time consuming factor (even on a local machine). On the
other hand, as far as I know, mwm does this:
- Move the window
That's not an excuse, but it partially explains things.
> I took a bit of time and wanted to try opaque window moving, and I was
> surprised. I had like 30 different applications open on one screen (like
> xdaliclock, xclock, xbiff, xterm, xmessage etc), and moving windows with lots
> of graphics over top of all these other programs showed no signs of slowing
> down the movement. The same testing done on fvwm2 showed noticeable slow
> down.
Fvwm does extensive redrawing of the window frames (unless you
enable the SaveUnder style that is). This is exactly what I'm
working at right now. When I'm done, opaque motion will be
lightning fast (at least as far as fvwm is concerned - I can't do
anything about applications that redraw a lot).
> Maybe since openmotif is open sourced, you guys could borrow some of
> their code if anyone cares.
Not unless we want to go back to the window manager stoneage ;-)
There isn't much in the window motion code that can be optimised
anymore (at least since I fixed that brain dead bug that slowed it
down so badly). The improvements have to be made in a different
area: drawing the window borders.
> This is just a thought anyhow. Unfortunately,
> I'm short of programming skills. I don't understand how all these different
> window managers can be so different with moving around a window, but I'll
> leave my ignorance about X for you guys to answer :-)
The list above may explain it a bit. Also, not every WM
programmer cares much about the performance.
> Btw, their non-opaque window moving is nice as well. What do you think if
> there would be a configurable way of telling fvwm how to draw non-opaquely,
> but defaulting to the traditional rubber-band method. Maybe this could be a
> separate module. So instead of a box with bands crossing each other, you
> could have a rectangle with lines of configurable thickness like in mwm.
> Maybe there's other ways you could handle the moving of a window as well. I'm
> sure it's possible you could add an extra configuration for such a thing while
> maintaining compatability and defaulting to the old rubber band movement stuff
> if you wouldn't do it in a separate module.
I'm not sure why one would need that in a module. The code to
talk with the module would be far more complicated that doing it
in fvwm. I'm not against it, but on my personal to-do list
(sorted by importance) it would get number 387 ;-)
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt_at_gmx.de
Reply-To: 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.
Received on Tue Mar 19 2002 - 13:38:31 GMT