On Sun, Mar 17, 2002 at 07:02:43PM +0100, Dominik Vogt wrote:
> 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).
>
Ok, I understand that. Applications do their own redrawing. But are you
saying that redrawing the window borders is the *ONLY* bottleneck that fvwm
has with opaque window moving?
> > 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.
>
I agree, useability would likely come before anything else.
> > 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.
Okay, maybe it was a silly idea, but I've seen some other WM's which have 3 or
4 different ways of doing non-opaque window moving, which might bloat fvwm2 a
little bit (which is why I thought of a module). But I think one other method
for non-opaque in fvwm2 itself would be good. Anyways, just for the record, I
compiled xmms 1.2.7, and it works perfect, no crashes on restarting fvwm2
the 20 or so times I tried restarting. So if anyone else complains about it...
>
> 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 Sun Mar 17 2002 - 17:04:02 GMT