
|
[haiku-appserver]
||
[Date Prev]
[03-2005 Date Index]
[Date Next]
||
[Thread Prev]
[03-2005 Thread Index]
[Thread Next]
[haiku-appserver] Re: private development
- From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Fri, 25 Mar 2005 08:04:51 -0500 EST
> BTW, that makes me wonder:
> Wouldn't it be better to split the server protocol commands
> definition ?
> I mean, currently we have a big enum: http://svn.berlios.de/viewcvs/
> haiku/haiku/trunk/headers/private/app/ServerProtocol.h?rev=11944&view=
markup
> but that way it's hard to tell what's there and what's not, what does
> what, etc. And it will become more and more complex.
> I was thinking about various enums like:
>
> enum GraphicStateCommands {
> AS_LAYER_PUSH_STATE = 0x1000,
> ......
> };
>
> enum DrawingCommands {
> AS_STROKE_LINE = 0x2000,
> ....
> };
>
> etc. etc.
For quite some time I've been trying to figure out a way to simplify
ServerProtocol.h -- figuring out message codes is a mess and the file
itself doesn't have much organization. Thank you! That is an excellent
idea.
> About the graphics acceleration in Painter:
> I know there are 2 ways to accelerate drawing:
> 1. Accelerate some basic drawing methods (StrokeLine, StrokeRect,
> FillRect, etc.).
> 2. Draw (without acceleration) to an offscreen bitmap and then use an
> accelerated blit to copy the content of the bitmap to the screen.
>
> 1. is what beos does and what we should do imho, especially because
> those commands are what the current beos drivers accelerate, what
Rudolf worked on, etc.
> Obviously my opinion doesn't count much as I didn't write any single
> line in the app server, but still I wanted to express it.
The only opinion that doesn't count for much is the one which isn't
expressed. :)
> And now for the true reason I'm posting here:
> I'd like to add (in the more or less foreseeable future) support for
> BDirectWindow in the server. I think I'll need to add some methods to
ServerWindow. I have some questions, though:
>
> Can I get a pointer to the frame buffer from ServerWindow ? how?
Not currently, but it wouldn't be difficult to tweak DisplayDriver to
allow for access. Getting access to the DisplayDriver is simply a
matter of calling desktop->GetDisplayDriver(). The desktop object is
one of the few globals in the server and GetDisplayDriver returns the
active driver. The tweak would likely be similar to the AcquireBuffer()
method. Using the buffer pointer might be a bit more interesting,
considering that the DisplayDriver subclasses implement this method
differently and some might require locking.
You could think of ServerWindow and WinBorder working as a pair.
ServerWindow generally is for message handling and management
activities and WinBorder takes care of graphics handling, like hit
testing, maintaining clipping regions, and so forth.
> Can I get the current clipping region of the window from ServerWindow
> ? How ?
I might be wrong on this one -- Adi's the expert on this -- but I think
it would be by calling ServerWindow::fWinBorder->GetClippingRegion().
--DW
|

|