Slashdot Mirror
FVWM-Crystal 3.0.4: Speed and Transparency
michuk writes "PolishLinux.org has published a review of FVWM-Crystal 3.0.4: "FVWM-Crystal is an eye-candy, functional and ultra-fast desktop environment for GNU/Linux and UNIX, based on FVWM. Crystal can be used even on very old machines, thus it is a noticeable alternative to popular desktop choices like XFCE or Fluxbox.""
Fvwm-Crystal is really nice, it shows how powerful and flexible Fvwm can be while still being light and fast. But its main drawback is that when something goes wrong, you are screwed unless you know Fvwm very well, and this is not something easy to achieve (for those who don't know Fvwm, just look at the man page.
Also, while we are on the subject of Fvwm, check out Metisse, a nice experimental Fvwm-based OpenGL desktop. I'm not sure if it's still actively maintened though. It would be a nice thing too if they ported it to Xgl.
My guess is that part of the problem results from having so many different toolkits that must be loaded into memory from the hard drive first. I know what you mean - KDE apps under fluxbox start slow - but when one opens Firefox, Kmail, and OpenOffice one starts up what are essentially three completely different systems for rendering graphics (particularly in the case of OpenOffice).
I can't help but believe that there is a LOT of redundant activity going on there, that could be avoided if we identify what is ACTUALLY DIFFERENT about the way GTK, QT, OpenOffice, etc are doing things at the graphics level and abstract everything they are doing the same onto a common library. I can see programmers working differently with different styles, but the libs should be reduced to accomidating those styles when possible.
I've been using FVWM for about a year now, and it's absolutely amazing at creating a desktop environment that increases your productivity. Since it's so flexible, I suspect the advantages are not limited to someone who uses their desktop like I do, but for virtually anyone.
Some of the key features that help me include
- scrolling on a title bar shades
- scrolling on the desktop switches to the next virtual desktop (I use 8)
- and a Quake-like console bound to ALT+1
And I'm a minimalist, I've read forum posts where some people have ALT+some click doing something radical, and mouse gestures doing others. Little things like that are useful enough that I don't care it takes an extra second or two to launch some programs, I make up for it plus (arbitrary number) in handy features.I just wish it was easier to edit the config, or at least have a (near compelete?) tutorial for editing the
There isn't an FVWM 3 - it's version 3 of this theme that runs on top of FVWM 2.5.
I made the switch to FVWM 2 through a lot of other window managers. I held on to the 1.x series 'til enlightenment DR13 ( I think), then gnome/sawmill was working enough to use, then after a few years went back to FVWM. I like 2.x much better - my current config doesn't do a whole lot 1.x doesn't do, but there's a trick or two I pull that I'm pretty sure 1.x wouldn't let me get away with.
One question though - if you're running the same binary, is it still linked with libc5, or were you an early glibc convert?
Those who can't do, teach. Those who can't teach either, do tech support.
1. The client/server architecture of X uses sockets. In the case of Linux, domain sockets are implemented as shared memory, same as in NT 3.51 and earlier. But it's still a kernel function to manage that stuff.
2. Context switching between applications or whatever and the X server. Context switching is handled in the kernel. A userspace switch is probably a good order of magnitude slower than a kernel switch. X generates a lot of round-trip traffic, though I guess that depends on toolkit implementers as much as anything else.
And probably a lot more things that an actual expert on this stuff could talk about. Basically, any X drawing event could be a context switch, and since X has a lot of events (which is why it sucks over slow links, and Microsoft's RDC doesn't), that's a lot of switching. I seem to recall reading a paper ages ago about how to minimise X events, like certain caching strategies, but I don't know if these are used by toolkits or not.
It is true that the way X and Linux work induces a lot of user-kernel switches and context switches. However, that doesn't mean that this has to be the case for any combination of kernel and graphics subsystem. I can very much imagine a system where applications acquire a piece memory to draw on, and all the display server needs to do is manage which pieces of memory go where on the graphics framebuffer (the video hardware might take care of the z-ordering) and send events. This would severely reduce the traffic between the clients and the server, and thus the number of switches of any kind.
``I seem to recall reading a paper ages ago about how to minimise X events, like certain caching strategies, but I don't know if these are used by toolkits or not.''
Probably one of lbx (doesn't gain you much), dxpc (gains you quite a bit) or nx (gains you a lot). They all compress requests (reduced traffic), bundle request (fewer packets and switches), and cache responses (eliminating certain sequences altogether). All this is done on the raw X protocol stream, so it's transparent to applications and toolkits. nx also offers replacement X libraries that use the more efficient protocol, and freedesktop.org has been working on next-generation X libraries as well.
Please correct me if I got my facts wrong.