On Wed, Apr 20, 2011 at 05:23:18AM -0700, Tom Cooksey wrote:
I guess the bottleneck will probably be the window compositor, as it will need to have a reference to all window back buffers in the system. So, do any of the DRI folks have any idea how many windows (with back buffers) a typical desktop session has? Do minimised windows have back buffers allocated in X11?
In a traditional X11 composited environment, all top-level window front buffers are redirected offscreen to their own memory (not only back buffers).
Even if there were as many as 100 top-level windows (which seems excessive), each triple-buffered, that's still pretty far from the 1024 limit?
If the process doing the compositing is the X server itself (rather than a direct-rendering compositing window manger), there is already file handle pressure, due to each client connection consuming a socket, plus all of the device nodes needed to open for input and output. If each client conservatively creates only one window, then we hit the limit at less than 512 clients. (Throw in a few clients like the gimp that create a whole bunch of top-level windows and you use them up more quickly.)
Admittedly, the default compile-time MAXCLIENTS in the server right now is 256, but, e.g., Red Hat has patched their servers since 2007 to bump that to 512 [1], so presumably somebody is hitting the limit already and uses more than 256.
I think somebody mentioned that the X server runs as root so it can just change its ulimit, but I don't think that's a good argument since we're actually trying to get away from X needing to be suid root.
[1] https://rhn.redhat.com/errata/RHBA-2007-0756.html
- Robert