Subject:
RE: compiled font size
From:
Vidar Hokstad ####@####.####
Date:
13 May 1999 21:22:03 -0000
Message-Id: <Pine.LNX.4.10.9905132253190.2715-100000@a.ncg.net>
On Thu, 13 May 1999, Greg Haerr wrote:
>
> >
> > #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.
After thinking about it a bit, I agree that DrawPixel probably would be
the only function where this would be an real performance benefit of
any magnitude... If we use a macro like above, the compiler should be able
to optimize inner loops on font rendering etc. quite well on it's own,
including doing loop unrolling etc, and suddenly make DrawPixel
viable for those functions, so that they can be moved into the mid level.
Also, note that I still believe that those who write drivers should
consider writing specially optimized versions, if necessary, but the macro
approach can reduce the performance hit of providing a set generic
mid level functions for font handling etc., so that drivers can be written
more quickly (then optimized versions can be added to the driver later,
instead of being required to get it to work).
> > 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.
Agreed. But for instance for the font functions, plotting pixel by pixel
is a clean and acceptable way of doing it as long as you can inline the
pixel plotting, but the moment you have to do a function call indirectly
via a jump table, it suddenly cost a lot. Which is why I suggested the
macro approach for DrawPixel (as an _addition_ to the function in
SCREENDEVICE, not a replacement - and drivers who provide their own
optimized font handling etc., could just leave the macro defined to it's
default value).
> 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.
Increasing performance beyond what we have now isn't really my point. But
inlining DrawPixel through a macro like above, would let us move the font
handling into mid level without _loosing_ performance, and thus reducing
the amount of code replication in the drivers.
Regards,
Vidar
