[haiku-appserver] Re: private development
- From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Wed, 30 Mar 2005 09:22:19 +0300
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.
Other related posts:
