[interfacekit] Re: Graphics Drivers and the App Server (LONG)

DarkWyrm wrote:
>> doing.  We can probably do an awful lot of our development (or
>> prototyping, at least) with a BWindowScreen-based "app_server", and
>> translate that pretty smoothly to using the drivers directly.

> I actually implemented something like this when I was bored tonight. I
> haven't implemented much of anything, but it's a start. You can start it, and
> pressing a key will shut it down.

So this isn't anything more than a BWindowScreen app that handles a
single key stroke, right?  Hmm ... probably not worth checking in. 
Dunno.

> AtheOS uses a layer system which we could probably use conceptually without
> much problem. As for messaging, I've read up a little on it. BMessages are

Are you familiar enough with the AtheOS layer system to write a little
something up about it?  That would save everybody else some time.

> Flattened and then dumped to the port, where they are Unflattened. This is
> why the docs recommend not using messages with as much baggage as JFK on Dec.
> 23rd. ;) I'm going to assume that this is the way that apps tell the server
> what needs redrawn - post a message with a BRect attached. When the
> app_server goes to redraw, flush the queue and dump each layer's invalid
> rectangles in a BRegion & draw it. My only question: would it be at a
> reasonable speed?

The app_server should tell the windows what areas needs redrawing (since
it knows what is where and who has clipped who); the window can then
determine which views need drawing locally, or even simply call each
view to draw, trusting that views will "do the right thing" and check
against the clipping rect to see if they need to draw.  At this point,
views which are drawing issue their drawing commands, which the
app_server executes on its side.  I don't get the impression that a
BMessage is what's used; it sounds more like a a raw port write of a
binary data stream.  I'll have to comb the docs for some evidence to
back that up, though.

> Accelerants AFAIK are user-space addons which are loaded via the
> B_OPEN_DRIVER call (or B_CLONE_DRIVER for direct-access classes) and then
> getting the accelerant hooks via B_GET_GRAPHICS_CARD_HOOKS. The Advanced
> Topics book has all this junk, but controlling the card with the accelerant
> (or not) appears to be just a matter of control_graphics_card calls and hook
> function calls.

I think you're confusing the accelerated functions obtained from the
driver with the relatively new accelerants which are used for 3D
acceleration and the like.  The latter is what I want to know about. 
Maybe these things are only available with the new OpenGL ... nope, just
checked.  See /boot/beos/system/add-ons/accelerants.  There are a whole
bunch in there.  Just did nm on stub.accelerant and it definitely seems
to be, in great part, a cover for the "accelerated" functions obtainable
from standard drivers.  There are some intriguing new symbols there like
"stub_get_engine_count", "stub_acquire_engine" and
"stub_release_engine"; what exactly is an "engine"?  I have a feeling
that figuring out how accelerants work is going to be a key thing.

e

Other related posts: