X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: David Bolen Newsgroups: comp.os.msdos.djgpp Subject: Re: GRX is sooo slow Date: 29 Aug 2005 19:41:41 -0400 Organization: Fitlinxx, Inc. - Stamford, CT Lines: 33 Sender: db3l AT CTWD0222 Message-ID: References: <430f9e51$0$27171$91cee783 AT newsreader01 DOT highway DOT telekom DOT at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net sjIU4YwAe0oCdNiULEzFNwpMaaezV56NhsNQEyObi3z4GiInJ/ User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Florian Xaver 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