[aidenn0]

Kind of OT, but I've noticed both latency and battery-life hits for compositing WMs in X (compared to traditional WMs).

Are those things being measured at all in FF? It may be that the tradeoff is worth it (and I have no doubt it can be done better than the median compositing WM on linux), but it would be good to have that data.

On the other hand, it may be moot if Wayland does end up taking over from X.

[majewsky]

(Nitpick: Traditional WMs composite as well, they just do it on the CPU instead of the GPU.)

That's interesting. I remember the developer of KWin (KDE's window manager) saying that he considered disabling GPU compositing when the battery runs low, but he couldn't prove that this actually saves energy. In fact, on some configurations, GPU compositing was less power-intensive than CPU compositing.

[aidenn0]

I thought traditional WMs had the clients send the draw commands directly to the server, rather than doing any compositing themselves?

It's definitely true that different GPUs have different power profiles (and even the same GPU with different drivers).

[majewsky]

No Qt or GTK application sends draw commands to the X server anymore (except for the final "draw window-sized pixmap"). That only applies to xterm or maybe Tcl/Tk stuff.

[aidenn0]

This still isn't compositing. If I have 10 windows all with the same X/Y coordinates, the only window sending any draw commands at all is the top window with a traditional wm.

[infogulch]

Don't forget "race to sleep". If the GPU takes 3x more power but completes 10x faster and can go back into low power mode sooner that could be another power savings.