[haiku-development] Re: A tale of two accelerant API's

  • From: looncraz <looncraz@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 11 Feb 2013 15:35:03 -0800

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.


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.

--The loon

Other related posts: