Xref: news2.mv.net comp.os.msdos.djgpp:1030
From: t DOT s DOT abbott AT larc DOT nasa DOT gov (Terence Abbott)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: GRX 2.0 very slow???
Date: 12 Feb 1996 17:17:04 GMT
Organization: NASA -Langley Research Center
Lines: 23
Message-ID: <4fnsmg$k4g@reznor.larc.nasa.gov>
References: <Pine DOT LNX DOT 3 DOT 91 DOT 960211173633 DOT 92A-100000 AT ost1 DOT ping DOT de>
NNTP-Posting-Host: tsabbo.larc.nasa.gov
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

In article <Pine DOT LNX DOT 3 DOT 91 DOT 960211173633 DOT 92A-100000 AT ost1 DOT ping DOT de>, 
sturm AT ost1 DOT ping DOT de says...
>
>
>Hello all...
>
>Just one question... I have got libgrx 2.0 (no beta-version mentioned) 
>and djgpp 2.0 beta 4. I noticed that graphics, especially 
>bitblt-operations, is very slow, whether under DPMI or not. For example, 
>I wrote a program doing 200 bitblts with a block of 200x200, which took 
>about 45 seconds on my 486dx/40 with 20 meg. I wrote a simple routine 
>doing something similar to a bitblt by copying every pixel into an array 
>with GrPixel and putting it on screen again pixel by pixel. This made 
>about the same speed. Can't be alright, can it???
>What I want to know, is the current libgrx still beta or is there any 
>other known reason for this funny behaviour??
>
I've had a similar problem invloving the mouse cursor.  It seems that
it too involved the bitblt function. Csaba was kind enough to provide
the following:  the 16 color functions have not been optimized (the
code itself, not the compiler flags).  I switched to to 256 color
mode and go a 2X increase in performance.