Subject:
RE: compiled font size
From:
Greg Haerr ####@####.####
Date:
13 May 1999 20:39:23 -0000
Message-Id: <01BE9D4E.2A999230.greg@censoft.com>
>
> #define DRAWPIXEL(_x_,_y_,_color_) scrdev.DrawPixel(_x_,_y_,_color_)
>
> In the GGI driver file (I've just written one :-):
>
> #ifdef DRAWPIXEL
> #undef DRAWPIXEL
> #define DRAWPIXEL(_x_,_y_,_color_) \
> ggiPutPixel(vis,_x_,_y_,palette[_color_])
> #endif
>
I think you've got kindof a neat idea here, it does allow for some
neat trickiness in allowing any kind of low-level driver interface to be brought
in without stubs. This would allow less procedure call overhead, certainly.
I don't really think you're going to see much speed improvment, though. I've
found that the only really bad area is DrawPixel. DrawPixel *can't* be used
to draw lines, it's way too slow. I think we should try to run without
too much optimization yet, just to get a better idea of where the speed improvement
needs to be.
I have a lingering bigger problem, though, with this good idea.
I'm afraid, as I mentioned in another email, that ultimately nanogui is going
to have to commit to a specific architecture to really get not performance, but
functionality in the overall project. As an example, I think that we need a "GC *"
first parameter in all the driver functions, so that each driver can effectively
see all of what it needs (draw mode, text background, fg color, etc) without
copying a bunch of gr_foreground globals etc like it does now. This may
seem like not a big deal, but before you know it, all the driver routines have
to have access to too many globals, and the whole thing is a big mess. The
only reason I haven't done this, is because I'm still looking for what kind of interest
there is in other people writing drivers, or, better yet, using other drivers that are
already written (because it's a huge pain to write all this stuff again and again)
> And for raw VGA drivers, we could leave the default macro, or plot the
> pixel directly. It may make it possible to move a lot of logic out of the
> low level drivers without hurting performance (it could still be possible
> to override the generic code if really needed).
I'm trying to move as much logic as possible out of lower level
and into mid level device indendent routines.
>
> Another alternative would of course be to loose the SCREENDEVICE jump
> table, and just have the drivers use the same function names, so we could
> let GCC inline performance critical functions.
>
Inlining is a good idea, but, I think real "engineering" graphics-intensive
applications that draw a bunch of diagonal lines and plot individual points would
see any improvement. Rectangle fill thru hline and vline is still quite fast now.
> What do you think?
>
> Regards,
> Vidar
>
>
