[haiku-appserver] Re: private development
- From: "Stephan Assmus" <superstippi@xxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Fri, 25 Mar 2005 12:04:44 +0100 CET
Hi,
> 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.
Ok, eventually I'll do this, once I better know my way arround.
[...]
> > 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).
I'm not absolutely sure on this, but when I declare a method "inline"
like so:
inline const SomeType* GetSomething() const { return
fPrivatePointer; }
Wouldn't that be just as performant as using the pointer directly? The
method also makes it clear, that it is ment for read-only access. Of
course, even though "SetSomething()" could also be "inline", I'd almost
never do this. But it could be done just the same. The difference then
is, that you can change the method later from inline to implemented in
the cpp, should it need to take care of additional things. And most
importantly, client code doesn't need to be changed.
[...]
> 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.
Yeah, when you express it in milliseconds... :-)
> 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.
I understand what you're saying. But Painter is pretty slow compared to
the original app_server. I don't want to drop the idea of implementing
it all by ourselves. Painter on the other hand, has it (almost) all
right now. So I had thought, that the best thing would be to implement
a Painter version of DisplayDriver along side the existing code. This
means I will make a true abstract base class from DisplayDriver, moving
all the existing code from it into a new class. Something like
"DisplayDriverImpl" or "DisplayDriverOrig" maybe. Then, there will be a
second class on the same level "DisplayDriverPainter", and both classes
are an entire implementation of the DisplayDriver API. I know what you
had in mind when designing DisplayDriver, only some methods needed to
be virtual, others could be implemented (with clipping) in the base
class. However, from what I have seen in the code (briefly yet), the
implementation of the clipping seems to be wrong. For example, you
cannot clip a line with one pixel width the same way in which you have
to clip a line which is thicker.
Once Painter is in place, we can test other parts of app_server for
completeness (hopefully right under Haiku) and worry about the
drawing_speed later. Either we find good ways of speeding up Painter,
or we have to roll our own implementation by extending the second
DisplayDriver version. But let's worry about that later. In any case,
there is never anything wrong with a completely abstract base class.
And changing it back is very easy.
Best regards,
-Stephan
Other related posts:
