[haiku-appserver] Re: private development
- From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Fri, 25 Mar 2005 08:54:58 +0200
Hi Stephan,
Stephan Assmus wrote:
> Anyways, since the big cleaning has started, how about structuring the
> app_server source into sub folders? For example, there could be a
> folder "unused", where all stuff goes, that is currently not even used,
> for example PixelRenderer and Clipper. Since we've got svn now, these
> classes or their functionality can be easily put back to use. There
> could be a folder "display_driver",
fine by me.
> for the files related to that, and
> maybe a folder "layer". Other ideas?
Layer classes are the essence of app_server, I think they should stay
in .../app.
There are some other classes that I think should stay in this folder as they
_are_ the app_server,
and here I mean:
ServerApp/ServerWindow/AppServer/WinBorder/DefaultDecorator/Desktop/Layer/
LayerData/RootLayer/Workspace. The other ones, "app_server services", you can
organize them into
Cursor/Picture/Bitmap/Font/Utils/Unused - that is if DW agrees.
> Right now, I'm trying to understand the structure of app_server and to
> see which part uses which.
For what it's worth, once the app_server stucture is completed I do
inted to
write a document exlaining app_server's architecture. At least the parts I am
working at. :-)
> From what I noticed, there is a lot of
> places, where the members of classes are directly accessed. Maybe there
> are good reasons for that, but from my experience, it makes it harder
> to change stuff later on, should it be needed. The purpose of C++
> classes, is to have an encapsulated object, that cannot be brought into
> an unkown or invalid state from the client code which uses it.
> Therefor, there are public functions to access private members, and
> these functions can take care of always maintaining a valid internal
> state.
Yes, we know, but don't worry. After app_server reaches an almost beta
stage we will
clean the code so that things would be clearer from C++'s point of view.
However, some classes are friends and those will stay like that because
they need frequent
need of private members, and every time calling a public method which returns a
pointer to the object
in question imposes penalty on performance (method/function call overhead).
> Here is what I have in mind: app_server has somewhere an instance of
> Painter. Whenever a drawing command is issued, it updates Painter to
> the graphics state of the client, and performs the drawing request. The
> Painter is probably attached to some frame buffer in main memory, and
> after Painter has manipulated it, the server would need to take care of
> transfering the respective region to the graphics frame buffer.
> I looked at the DisplayDriver class. This seems to serve as the
> complete drawing backend. When I try to integrate Painter later, I
> would probably implement this along side the existing DisplayDriver
> usage with a compile time switch. I would have to invent a similar
> class to DisplayDriver, which only does the transfer from the main
> memory frame buffer into the graphics card frame buffer.
>
> Another approach to intergating Painter would be to create another
> derived DisplayDriver class, that implements all the existing
> DisplayDriver functions on top of Painter. Would this be a better thing
> to do? The clipping of the client seems to be passed by the DrawData
> object that each call gets, right?
[more below]
> This reminds me of another question
> I had - is the gaphics state stack already in place?
Did that thing long ago. As far as I remember, yes it is in place. The
problem is
I don't remember how exactly it is used. :-) Have a look into
ServerWindow::DispatchMessage (AS_LAYER_SET_STATE / AS_LAYER_GET_STATE /
AS_LAYER_PUSH_STATE
/ AS_LAYER_POP_STATE / AS_STROKE_XXX / AS_FILL_XXX).
Oh, :-) I don't know if the graphics stack works as expected. :-P
Regarding Painter integration... I don't know what's best...
Painter is a complete drawing framework, it has all we need, and as far
as I understand
it's performance is quite high. When we restructured DisplayDriver interface,
we thought all
drawing and clipping should be done by DisplayDriver class, and only methods
which draw lines,
rectangles, and copy rect operations should be left virtual so that we can
implement backends for
directly drawing into video memory, drawing into a BWindow/BView, drawing into
a buffer (bitmaps) or
using BDirectWindow for testing under R5.
Now, both DisplayDriver and Painter class offer _the same_, high-end
drawing facilities.
I think our problem is not how to make use of Painter in a DisplayDriver
subclass, but which one of
the two to chose. DisplayDriver has enough drawing primitived implemeted but
it's not as complete
as Painter is. Another thing holding back DisplayDriver is the fact that it
_still_ does not clip
primitives or fonts from the freetype engine.
If you ask me, I think we should _drop_/addapt DisplayDriver _and_/to
use Painter class which has
all these nice things already in place.
bye,
Adi.
Other related posts:
