[haiku-appserver] Re: private development

  • From: "Stephan Assmus" <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 24 Mar 2005 17:58:53 +0100 CET


> 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,

Other related posts: