[haiku-appserver] Re: private development
- From: Stefano Ceccherini <burton666@xxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: 29 Mar 2005 14:04:04 -0000
Hi Adi,
> ServerWindow-WinBorder is exactly like BWindow-BView.
>One has to deal with
>the communication the other with the graphics. The clipping >region is not a
>ServerWindow's attribute, but a WinBorder's (Layer's too, as >WinBorder is a
>subclass)
Okay, now I see the picture.
>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.
> 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.
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.
Basically it works like this:
- When a BDirectWindow is created, it receives a "notification" ; the server
says: okay, you can do what you want with the frame buffer, here's a pointer to
it, but just mess within this clipping region: here's it...
- The BDirectWindow subclass (not BDirectWindow itself which does nothing) do
its own clipping, taking into account the clipping region passed by the server,
and then do what it wants (usually it writes to the frame buffer pointer given
by the app server, but can do anything like reading from it or doing DMA to the
PCI space, etc.)
- 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.
Hope it's clear enough.
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.
Stefano Ceccherini aka Jack Burton
---------------------------------------------------------------
Scegli il tuo dominio preferito e attiva la tua email! Da oggi
l'eMail di superEva e' ancora piu' veloce e ricca di funzioni!
http://webmail.supereva.it/new/
---------------------------------------------------------------
Other related posts:
