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

>I think any BWindowScreen examples we can lay hands on will be very 
>instructive here.  It's about as bare-metal as BeOS graphics programming 
>gets, in or out of the app_server.  In fact, it's basically just a nice 
>class wrapper for the graphics driver API, when you think about it.  
>Where there are graphics card hooks available 
>(BWindowScreen::CardHookAt() or by passing the B_GET_GRAPHICS_CARD_HOOKS 
>opcode to a driver's control_graphics_card() function), use them to do 
>your drawing.  Where they aren't, you get to experience the joy of 
>drawing directly on the frame buffer, which is gotten via the 
>graphics_card_info struct (BWindowScreen::CardInfo() or the 
>B_GET_GRAPHICS_CARD_INFO opcode for drivers).  In fact, I'm thinking 
>BWindowScreen will be a good testing ground for a lot of what we'll be 
>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.

>Actually, I distinctly recall it being said in either the lists or the 
>newsletter that messaging (via raw port writing) is *exactly* how 
>windows communicate drawing commands to the app_server.  In fact, I 
>suspect that when a window is told to draw it goes through the view 
>list, back-most to front-most, asking each effected view to do its 
>drawing (with some special handling for views which are drawing on their 
>children).  These commands are queued up in a buffer (a straight binary 
>data stream?) which is sent to the app_server when either all the views 
>are done drawing or some view calls Flush() (or is it Sync()?).  
>app_server takes it from there, communicating more or less directly with 
>the graphics driver (which is actually loaded as a userspace add-on).  
>Which is not to say this is necessarily the *best* way to do it; I'm 
>plenty open to any brilliant ideas of how to do it better in a "thread 
>for each window" environment.
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 
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?

>Man, if he can clue us in to how to communicate with the accelerants, 
>that would be suh-weet!  Also, you might want to fly the 
>BWindowScreen-as-app_server-surrogate idea past him.  Any info on how 
>input_server works with app_server (and anything else it might talk to) 
>would also be great.
The BWindowScreen-app_server-replacement should be relatively easy to do 
concerning the drawing & stuff, considering the app_server basically hands 
you the buffer on a silver platter.
    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.

>listport, eh?  What exactly does this do (other than the immediately 
>obvious)?
Undocumented AFAIK, but it does the obvious.

>I haven't, but getting hold of it would be mucho cool.  Maybe George can 
>help us here?
I'm looking into it.

--DW

Other related posts: