I've noticed for a while that Fluxbox is actually kind of slow in most distros. Things like window redraws are clearly visible on a Fluxbox desktop, on my Pentium Dual laptop. For a while I ascribed this to slow GTK themes. It's a little annoying, but not bad enough that I can't deal with it on a modern computer.

Recently though I tried compiling Fluxbox from source. On a whim I tried some heavily optimized CXXFLAGS (-O3 -march=native -fomit-frame-pointer); and on logging into my new desktop I was surprised to find that the sluggishness was gone. Window redraws in GTK programs were not visible any more, and there was less delay when starting new applications.

Thus my question: in terms of desktop responsiveness, how much does a window manager count?

e.g.

How much overhead, in terms of CPU cache use and function calls, does window manager code usually incur?

Should the window manager have any effect on widget redraw delays when moving, resizing, or uncovering a window? Or on how long it takes for popup menus to appear?

In general, in what operations other than the drawing of window frames, etc. can a window manager incur additional latency?

It counts in 2 ways:
If it is bloatware, talking to itself more than actually doing anything, it can slow you down a lot. I am thinking kde, and increasingly gnome.
If it is poorly coded you may lose somewhat. I have found little gained by tuning compiles - perhaps that has something to do with the cpus I buy :-).

Slackware offered xfce as a low cholesterol window manager. I was instantly sold on it.

Fluxbox is lighter than XFCE. XFCE is a desktop environment; Fluxbox is a window manager.

When I first switched from KDE to XFCE to Fluxbox (mumble) years ago, I noticed a significant difference because of Fluxbox's relative lightness. Since then, Fluxbox has been my default choice for a window manager, though lately I've been having fun with E17.

Gullible Jones, what are the specs of your computer? I have never encountered the symptoms you've described with Fluxbox.

By the way, here's what top reports on this computer; you'll see that Flux is using minimal resources; swisswatch uses more:

This computer, by the way, serves primarily as my file server, though I use it while reading LQ while I watch old movies on the one next to it, over there ---------------------------->

The last time I rebooted it was for a kernel upgrade:

I've found fluxbox a bit slower than openbox but if I were doing anything other than watching it I don't think I'd notice.

Window managers are not always lighter than desktops. My records show Xfce on SalineOS and ZevenOS slightly lighter than Openbox on CrunchBang and SalentOS. In fact, the differences between distros can be huge: with Xfce, Fedora uses twice as much RAM as ZevenOS. The one wm that seems consistently light is Ice.

On my ThinkPad T61 (Slackware 64-bit), I've noticed no appreciable performance gain from using fluxbox vs. xfce. RAM usage is about 40MB less or so, idling, in fluxbox, but performance is about the same.

Having said that, I increasingly spend most of my time in no-X framebuffer sessions, which of course blows away all DEs and WMs in terms of performance and RAM usage.

Video mode may be important too. Try it in VESA maybe? Should let the card do most of the work.

I have used KDE (from slackware) on machines from a 166MHz to a 1.6GHz Athlon, and it is getting slower. On another machine I set up, with 1.3Ghz, KDE was intolerable and I have to use xfce4. I have had battles with the new security library KDE now requires (but xfce4 does not). Similar problems could be affecting your use of Fluxbox.

A visible update delay is not normal and for a manager it must be considered that it is in some distress somewhere. Most probable is a busy wait, with a timeout.

Any program can get into performance wasting busy waits, error recovery loops, and use inefficient interfaces. They may be due to configuration, missing libraries, or just having to use generic code and generic routines. All these things are affected by a custom compile. Even a default font that does not exist will be a problem when the code must discover this with every window manager draw.

Consider error recovery, missing libraries, busy waiting for unavailable devices, etc...
Look at the console that starts Fluxbox for any interesting messages. Does it shutdown cleanly or have have complaints about missing handlers ??
If you do not start Fluxbox from a console, then consider starting without a graphical interface and start Fluxbox from a console to see the feedback.
Slowdowns could be something like background file searching, self starting applications, music programs that you don't know are running (because they only minimize to the bar), and you must configure any add-ons to be less obnoxious.

When you make a custom compile, there is usually a configuration to what libraries and interfaces you have. You get an executable that has best code for your actual processor, which can include using advanced instruction sets (which can impact graphics handling).
It can detect the lack of a library, so it can remove some code and remove attempts to use that library. It might have changed some code from a generic poll to some other more efficient interface. Check in the compile directory for a compile configuration file and see what it detected and configured.

Actual drawing is handled by the X11 video drivers, which are not a part of Fluxbox.
Always consider that you might have changing drivers, or settings, during experimentation and have forgot about it.

(heh ...)

I rather suspect that these folks know that they are ultimately competing with Win-doze, which ... on a very good day(!) ... could not "out-perform" a paper (... airline, barf ...) bag.