[interfacekit] Re: BScreen (again)

On Mon, 28 Jul 2003 16:14:57 +0200 "burton666@xxxxxxxxx" <
burton666@xxxxxxxxx> wrote:
> > I'd be interested in their workings. :)
> > 
> 
> I'm glad someone is :P

I'm interested too, though I didn't want you to write it up just for 
me. :-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).

BPrivateScreen seems to have a sem_id member, which is acquired in 
WaitForRetrace() -- if not yet initialized, the method gets the sem_id 
from the app server. I suspect, all threads of all applications wait on 
the same semaphore for the vertical blank. I wonder a bit, how this 
works, but probably there is something like an undocumented 
release_sem_etc() flag that releases the semaphore exactly as often as 
necessary to unblock all waiting threads.

CU, Ingo

Other related posts: