[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.
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.
--The loon
Other related posts:
