nanogui: Thread: compiled font size

Vidar,
	I finally found time to get into your comments about the compiled font
size in bogl.  Is your concern that bogl uses longs per line of font, rather than, 
say 24 bits?  Or a format that uses just enough bytes (variable) for the character
width per character, along with pre-built chartable offsets?

	I can see that bogl uses at least an extra byte per scan line per character.


Greg

On Thu, 13 May 1999, Greg Haerr wrote:

> Vidar,
> 	I finally found time to get into your comments about the compiled font
> size in bogl.  Is your concern that bogl uses longs per line of font, rather than, 
> say 24 bits?  Or a format that uses just enough bytes (variable) for the character
> width per character, along with pre-built chartable offsets?
> 
> 	I can see that bogl uses at least an extra byte per scan line per character.

Yeah, basically. The code I sent Ben uses just enough bytes for the scan
line for each character. The drawing might be marginally slower, but
it should both save space and allow fonts (or individual glyphs) that are
wider than 32 pixels too.

Regards,
Vidar

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

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