On 2/11/2013 14:37, Axel Dörfler wrote:
Just keep in mind that the current API does not support this. And I haven't taken it into account either when I redesigned the app_server, so it might not be that easy to do.Bye, Axel
Trust me - I know ;-)I had a few ideas running around - from multiple Desktop objects (with corresponding window lists, etc...) to outright separating display/graphics output from application management (think two servers vs one..., one is system global, the other is per-user). Or using different Screen objects in various configurations...
The multi-server design is, technically, the simplest in terms of the logical end result and code complexity... Windows currently open a port to the app_server, now they would need to open TWO ports - one with the app_server, and another which was negotiated with the graphics_server by the app_server for drawing requests. This keeps drawing latency pretty much identical to how it is today, with two extra messages being passed when a window is created.
The app_server would then serve the Desktop, applications, settings, and logic for one user. The graphics_server would handle all rendering, mode setting, acceleration, cursors, hardware, connections to n app_servers, and window/view drawing requests into the frame buffer(s) on whatever screen to which they are attached. The exact division of labor is a little blurry, ATM... and it is a significant re-working of the code. Something post-R1 for certain. And not something to be done halfheartedly.
For now, the idea is to create code that is flexible enough to handle whatever design is ultimately chosen.