[haiku-appserver] Re: private development

  • From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Fri, 25 Mar 2005 07:51:10 -0500 EST

> 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?
My thoughts are for grouping them by function. I did this in my BeIDE 
project files so I wouldn't have to look at all the files all at once. 
The groups I used are Management (ServerWindow, ServerApp, etc.), 
Display Classes, Font Support, Support Sources (i.e. Utils.cpp, 
Angle.cpp, RectUtils.cpp) and some others I don't remember. Even though 
it's a bit of a guess for certain classes which do more than one thing, 
like RootLayer, it certainly makes the server's structure more obvious. 
What are you guys' thoughts on this?

>       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.
This is my fault, and is mostly laziness, and you have my apologies. 
The current DrawString that is in place is somewhat of a simple 
implementation. Ideally, one calculates the position of the characters 
to be drawn and then draw only the ones which are in the clipping 
region. Implementing clipping for DrawString is literally just a matter 
of reimplementing Blit* functions. A proper Blit  implementation would 
probably involve using AGG to dynamically handle the destination color 
space to increase flexibility and reduce code size at the same time. 
I'm currently doing just e-mail at the computer and doing as little 
computer-related stuff as I can for school because of the problems I'm 
currently having with my arms, so I'm out of a coding capacity for a 
while.

>       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.
I'm not so sure that's a good idea. Painter is considerably slower in 
some instances. We need to choose is the route of best performance. 
Some instances, such as straight lines without antialiasing, may be 
faster by not using AGG. Some parts of DisplayDriver are just plain 
difficult and calling AGG functions would speed up the development 
process. For the moment at least, Painter should be used to fill in 
what's missing. Going beyond fixing bugs and adding what's missing is 
pretty much just optimization, which we just shouldn't spend time on 
ATM -- there are bigger fish to fry, so to speak. :)

--DW


Other related posts: