Mail Archives: djgpp/2005/08/29/19:45:15
Florian Xaver <wosrediinanatour AT aon DOT at> writes:
> It would be much work, to port the library i am using to f.e. mgl.
> But GRX is sooo slow. Any idea to speed it up?(using VESA driver)
We don't use the VESA drivers, but you might want to verify that your
build process is making use of the optimized assembler routines that
GRX has for handling memory fills and copies, and that if there are
any conditionals within the video or frame driver files that might
pull in generic routines that you try to minimize that. The memory
macros are conditional on compiler type (presumably DJGPP), and you'll
want to ensure that you're compiling with optimizations enabled such
that they get inlined properly.
We use GRX on an embedded system running a 33MHz 486sx on a QVGA
screen (320x240) where it performs very well. I did have to implement
our own video and frame driver for our hardware, and one thing that
was very obvious was that the difference between the generic routines
and those I later wrote to make use of the optimized memory macros was
night and day. Also, compiling with optimization with those macros
was a major difference. Checking that you're getting the most out of
the lowest routines such as drawpixel (which I think is used in font
rendering), drawhline, drawvline and drawbitmap can give the most bang
for buck.
This may require some digging through the VESA implementation to see
just which code paths your particular device is using. As I mentioned
I'm not familiar with that particular driver, but at least you could
verify that you're getting the most out of the current code base
(e.g., using an optimized routines as well as the inlined memory
macros).
-- David
- Raw text -