[haiku-appserver] Re: private development
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 24 Mar 2005 17:58:53 +0100 CET
Hi,
> Attaching doesn't seem to work in this list. Anyway, as Ingo's
> development is not that sloppy (hehe), the server is in src/tools/jam
> and will be built alongside jam ;-)
I'm sorry, I should have figured. Well, hopefully, we're all on
broadband... :-}
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", for the files related to that, and
maybe a folder "layer". Other ideas?
Right now, I'm trying to understand the structure of app_server and to
see which part uses which. 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. Well, never mind, I'm just telling you my impressions. I keep on
reading through code hoping that I find a good starting point for
integrating painter.
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? This reminds me of another question
I had - is the gaphics state stack already in place?
Ok, I guess that's all for now.
Best regards,
-Stephan
Other related posts:
