[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
compiled font size
From: Greg Haerr ####@####.#### Date: 13 May 1999 16:27:51 -0000 Message-Id: <01BE9D2B.02DD1370.greg@censoft.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: compiled font size
From: Vidar Hokstad ####@####.#### Date: 13 May 1999 16:45:28 -0000 Message-Id: <Pine.LNX.4.10.9905131835030.2715-100000@a.ncg.net> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |