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

>It's funny that you mentioned the Advanced Topics guide. I've got it, 
too, 
>and read through it quite a bit last night after I logged off for the 
day. I 
>understand how the functions are called and actually accessed, BUT I'm 
still 
>trying to figure out what to *do* with them. Thoughts?

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.

>>thats maybe it.  I'm guessing all of this but drawing through messages
>>wouldnt be ideal (i think).  app_server is just a management thread, 
thats

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.

>I've been doing a *lot* of researching, so all this info is my high 
point for 
>today - it's been the Day from Hell (tm) today.

Man, you can say that again.  My jaw is literally *sore* from dropping 
so much.  I haven't had such an emotionally exhausting day since my son 
was born. =\

Sorry I've been practically MIA here, guys.  This will change starting 
now, I promise. =)

>1) The app_server does a *lot* of things, but the major tasks are GUI 
>management, starting apps, messaging, and dealing with input.

Which means the input_server will probably end up being our baby as 
well. =P

>2) The registrar (which is also a project of ours) publishes BRoster 
kinds of 
>things. It and the app_server are both contacted by a BApplication 
>constructor
>
>3) I've been in contact with George Hoffman at Be, who is the App 
Server guy, 
>and he is willing to give us any info which he can legally tell us. 
According 
>to him, this would be the kind of info that they would put in a 
newsletter.

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.

>4) We have a lot of resources to pull from: Be Advanced Topics, the Be 
Book, 
>the BeOS Bible, the Newsletter Archives, the BootScript, Sample Code, 
and the 
>list goes on.

Which we really need to start combing in an organized way; i.e., putting 
it all together in a document.  Take notes on what you find, guys!

>5) Some useful tools: AreaWatch, objdump, listport, ps

listport, eh?  What exactly does this do (other than the immediately 
obvious)?

>6) There was a dummy app_server used in debugging graphics drivers at 
Be 
>which was available by request to William Adams, but I can't track him 
down 
>or the program. Anyone seen this or have it?

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

>Concerning #1 (and to correct Yuri), the app_server manages screen 
>resolution, color depth, etc, by calling graphics driver functions. It 
also 
>manages the mouse cursor the same way. Anyway, if you kill everything 
but the 
>app_server and the input server, you *still* have desktops and apps 
that can 
>be run.

Yeah, as far as any regular app graphics are concerned, app_server is 
pretty much god.  Which would make us god creators, no? ;P

A few ideas that I wanted to throw out there.  We don't necessarily have 
to implement these for 1.0, but I think it would be advantageous to 
design with these things in mind:

* Using regions internally to represent windows, rather than rects.  
This will allow us to add the ability to do non-rectangular windows 
later in the game (not something I'm particularly fond of, but people 
get very excited about it)
* Building in a low-level interface to app_server which allows 
applications with multiple windows to be run in a single thread.  Doing 
this right will make native ports of Qt and GTK+ much easier to do, 
which can only be a good thing.
* Support for changing the colors of basic window elements (a la 
WindowShade).  I see far more screenshots of apps where WindowShade is 
clearly in use than not.  Again, not a big deal to me personally, but 
people dig it.
* Extending the support for window decor -- hopefully to the point where 
people can do decor add-ons or something to that effect.  The 
non-rectangular window thing will be pretty key here.  Same personal 
feeling as the others ...
* Support for full RGB(A) cursors, hopefully of arbitrary size.
* Alpha-blended transparency for windows.  More eye candy for the 
theme-crazed masses. ;)  Probably the hardest of the bunch.
* Support for full RGB(A) icons.  Don't know how much this would 
necessitate hacking OpenTracker/Deskbar, but I seem to recall app_server 
being an issue in implementing this.

Aside from the single thread idea, a lot of this is functionally 
pointless bells and whistles in my book (I rather like the spare, clean 
UI elements in BeOS), but people love this stuff, and I'd like to 
seriously explore at least not *excluding* the possibility of these 
additions in our design.  What I *don't* want to do is get so caught up 
in this kind of stuff that we're designing around these capabilities.  
Thoughts?

BTW, I was successful in trying to build a proxy lib test app.  I'll 
spend some time cleaning it up so it's a bit more coherent and post it 
for you guys.  I may then take a small chunk of time and try it with 
libscreensaver.so to take the proof-of-concept to the next level before 
tackling libbe.so.  The point being to show definitively that binary 
compatibility in the public interfaces is do-able, which for our team is 
of paramount importance:  it's one thing if all the screensavers have to 
be recompiled (not a huge setback), but if every GUI app would have to 
be recompiled ... well, you've all heard my rant on this before. ;)

Now off to bed, before my honey comes out here and tans my hide! ;)

e

Data is not information, and information is not knowledge: knowledge is not 
understanding, and understanding is not wisdom.
        - Philip Adams

Other related posts: