thoth@reef.cis.ufl.edu (Gilligan) (08/26/90)
Here at UF we have fixed all the simple bugs in vtwm including the "moving_icon" and the raiselower/lower bug. A patch for the moving_icon bug was posted earlier to this group by Steve Beaty and is (to my knowledge) perfectly correct. It happens to be the way we fixed it. The raiselower/lower bug can be demonstrated by "f.lower"ing a window. Its virtual window does NOT lower. f.raiselower has a similar problem. I don't have a patch for the xmh simplemenu problem and I have a sneaking suspicion that it might be Xmh's fault. Our patched source can be "ftp"ed from cis.ufl.edu in pub/fract (the only directory I can write to right now). I have sent mail to the author but he's gone till september. Once I can talk to him we can merge our changes onto his source and maybe it can become official Vtwm IS slower than twm. It has more data to keep track of. The main thing that bothers me is the time it takes our servers to move all the windows, and I have to make empty "streets" to "drive" down when I'm moving from workspace to workspace because the cost of expose events. Even if you don't expose windows you can slow your machine down with sheer numbers. An xpostit farm off in the corner can make a REAL difference. I use a color Sun 3/80. When I can use a Sun SS1+ I don't have to worry about speed any more because the 1+ is much to fast to be slowed down by some piddly expose events and text drawing. Ahh, what I wouldn't do for a color Sparc on my desk. -- /-------------------- "a window is a terrible thing to paste" -me ( My name's not really Gilligan, It's Robert Forsman, without an `e' ) --------------------/
brtmac@maverick.ksu.ksu.edu (Brett McCoy) (08/26/90)
In article <THOTH.90Aug25140850@reef.cis.ufl.edu>, thoth@reef.cis.ufl.edu (Gilligan) writes: |> I use a color Sun 3/80. When I can use a Sun SS1+ I don't have to |> worry about speed any more because the 1+ is much to fast to be slowed |> down by some piddly expose events and text drawing. Ahh, what I |> wouldn't do for a color Sparc on my desk. You are going to have the same problem on a color Sparc unless you get a GX board and run OpenLook on it. The color sparcs seem almost as slow as a monochrom 3/60. It will be faster than a color 3/80, but you would probably still want your highways between deskspaces. Too bad the universe doesn't run in a segmented environment with protected memory. -- Wiz from "Wizards Bane" by Rick Cook Brett McCoy | Kansas State University brtmac@maverick.ksu.ksu.edu | UseNet news manager.
toml@ninja.Solbourne.COM (Tom LaStrange) (08/26/90)
From article <THOTH.90Aug25140850@reef.cis.ufl.edu>, by thoth@reef.cis.ufl.edu (Gilligan): > I don't have a patch for the xmh simplemenu problem and I have a > sneaking suspicion that it might be Xmh's fault. > Nope, it's a bug in vtwm. > Vtwm IS slower than twm. It has more data to keep track of. The > main thing that bothers me is the time it takes our servers to move > all the windows, and I have to make empty "streets" to "drive" down > when I'm moving from workspace to workspace because the cost of expose > events. Even if you don't expose windows you can slow your machine > down with sheer numbers. An xpostit farm off in the corner can make a > REAL difference. Once the above bug is fixed, your response will even be slower. Sometime next week (8/27-8/31) you can try a new virtual desktop twm that will have much better performance when panning the desktop. It is modeled after the virtual desktop in swm and includes the ability to drag windows into and out of the panner. What will this new version be called? How about tvtwm? It is a new version, none of the code came from vtwm. -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501