[interfacekit] Re: BScreen (again)

> I'd be interested in their workings. :)
> 

I'm glad someone is :P

Basically, BScreen is just a proxy for BPrivateScreen.
In fact, every BScreen method just call the corresponding BPrivateScreen one.

On construction, BScreen calls a BPrivateScreen static method to get a 
BPrivateScreen object, which will be released upon destruction.

The interesting thing, is that there is only one BPrivateScreen object for 
BApplication, no matter how many BScreens one istantiates, and, for this 
reason, the BPrivateScreen constructor isn't called by BScreen, but by 
BApplication itself (in the get_scs() method, which basically does:

void
BApplication::get_scs()
{
  gTheScreen = new BPrivateScreen();
}

with gTheScreen being in a private header accessible by both BApplication and 
BPrivateScreen, I guess.).

BPrivateScreen is the one which is responsible of the communication with the 
app server through _BAppServerLink_ and _BSession_ (or Portlink, in our case).

On creation, it gets a color_map structure from the app server (can be done 
with two methods: one involving the allocation of a struct done by 
BPrivateScreen (_BSession_, unlike Portlink, doesn't do any allocation, it's 
the client who is responsible to do it), and reading the structure with 
_BSession_ (again, PortLink for us) from the app server, the other using 
BApplication::global_ro_offs_to_ptr(uint32 offset), which returns a pointer to 
the color_map struct within the app server's heap (I guess)).

What else can I say... 
well, the color methods (IndexForColor(), ColorForIndex(), etc.) are local, 
while the others ask the app server....
Oh, and the WaitForRetrace() call isnt' even implemented (or at least, it 
doesn't work on R5, at least with the Nvidia drivers).

I hope I was clear enough :)
Questions ?

Other related posts: