[haiku-development] Re: A tale of two accelerant API's
- From: looncraz <looncraz@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 11 Feb 2013 17:41:57 -0800
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:
