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.

- Raw text -