FreeLists / haiku-appserver / [haiku-appserver] Re: private development

[Adi Oanca <adioanca@xxxxxxxxxxxxxx>]

Ola,

Stefano Ceccherini wrote:
>>in the mean time it may change and because BDirectWindow does >clipping by 
>>it's own,
>>it is very much possible it would draw bogus.
> 
> No. :)
> Because when the window's clipping region changes, BDirectWindow is notified, 
> and it changes its clipping region too.

        :-)) "Unless BDirectWindow is notified somehow." Forgot to add that. :-)
        As I was suspecting, and you have confirmed, this is done by a 
semaphore.

>>      This is how I see things. I don't know how this is >implemented on R5 
>> and I will
>>study that, but I think just before BDirectWindow starts to >draw it should 
>>acquire a
>>semaphore that is internal to app_server and use the clipping >region 
>>app_server holds
>>for this window (should be shared through a memory area).
> 
> You don't need to study it, as I already did, and you can have a look at the 
> implementation to see how it's done.

        When I said "I will study that" I was referring to exactly that: having 
a look at what you did. :-)

> BDirectWindow doesn't acquire a semaphore when it starts to draw, as with 
> locking you would lose all
  the advantage you have by using that class.

[...]

> - If the clipping region changes (or when the resolution changes, or 
> whatever), the server notifies BDirectWindow releasing a semaphore.
  The various data (frame buffer pointer, etc. is contained in a shared area, 
but the client needs to know when this data changes.
  BDirectWindow acquires this semaphore, calls BDirectWindow::DirectConnected() 
so that the client can update its data,
  and then it releases another semaphore (which the app server was trying to 
acquire with a timeout of 3 seconds.
  If this times out, the app server crashes the application (yes, you've read 
well)).

> As you can see, BDirectWindow doesnt' need to lock every time it draws, as 
> the frame buffer is supposed to stay the same,
  and the clipping region too, unless the app_server says otherwise.

        Aha, I got it, it only locks when the server clipping region changes so 
that its "internal" one can be in sync.

> Hope it's clear enough.

        Oho, it's crystal clear. :-)

> What I need is just a pointer to the "real" frame buffer and the current 
> clipping region.
  It's okay (I think) if I have to lock to get the region, though.

        But you still need that lock app_server releases when BDirectWindow's 
clipping region changes. (and that shared area I think - 
have to see BDirectWindow implementation).
        Okay, should be easy to implement support for this class, we'll be 
doing that when I get to revamp the update code, OK?


Thanks,
Adi.