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

On 2/11/2013 16:04, Sean Collins wrote:
I have several computers in my home, because sharing computers leads to arguments. At the maximal sharing, you'd have several people, sharing a machine, at different times. It isn't a mainframe. 


Sean
This would prevent the arguments by allowing one computer to act as many. You just need multiple monitors, keyboards, and mice.
Honestly, though, with the price of computers, this is really only mostly useful for libraries, businesses, and schools - and then that would also require them to actually use Haiku, LOL!
The whole point of all this, though, really, is examining if it is worthwhile to bother providing support at the accelerant and app_server level, rather than really aiming to implement it fully - merely whether planning to permit it in the future is worthwhile.
It is very likely that the app_server will need to have a separate frame buffer per screen. Supporting this configuration would allow differing resolutions per screen and possibly even multiple video cards. The need to support multiple video cards is, IMHO, not there - multi-headed cards are the norm - but supporting differing resolutions certainly may be!
The next relevant question comes with the intention of the multiuser system. Is it desired to have concurrent user sessions? While this certainly seems like the way to go, I've rarely seen anyone actually use these features in Windows. Normally, they just open another browser window and do their stuff, minimizing whatever the other person was doing. We have workspaces which makes that even more efficient, LOL!
However, from supporting multiple frame buffers with differing resolutions per screen and supporting concurrent user sessions with multiuser, you really don't have very far to go to supporting multiple concurrent users with different monitors, keyboard, and mice - though I would see no reason to go as far as actually implementing that as part of Haiku in the foreseeable future, it may someday prove to be exactly what someone wants to do... we're talking in theoretical flexibility.
We need a vision for what Haiku will be post-R1 to determine the best way forward today. Will it be an efficient single-user focused operating system or will it be an all-out multiuser paradise?
Frankly, as cool as having all of the benefits of concurrent user sessions and like sounds, the situation is considerably more simple to handle in a non-concurrent multiuser system. You don't need to worry about multiple users making multiple requests at the same time. Meaning you also don't need to manage multiple contexts, application rosters, artificial memory barriers, or to worry about which user is running which application... as only "system" and the current user can run applications - and "system" applications would not require any special treatment - unless the current user has limited permissions...
Personally, I'd say go with a single concurrent user design, then if people want all these other things they can just run Linux and run Haiku in virtual machines. It seriously makes things MUCH easier. I'd also say forget about supporting differing screen resolutions on multi-headed setups. One video card. One active user. One common resolution. One Desktop, either extended or mirrored on other screens. One CompositeEngine. One frame buffer. One context. This supports, literally, 90% of all usage scenarios. And you can do this much better with the limited resources Haiku has at its disposal.
This means, don't design any special accommodations into the accelerants and app_server. This also means there will only be one BScreen, which further simplifies the app_server internals as compared to today. Mirroring can, of course, be done to different outputs, at differing resolutions. Just scale away... IIRC the current accelerant API already supports that (screen to screen blitting w/ scaling and aspect ratio preservation). 

--The loon

Other related posts: