From:	broeker AT acp3bf DOT knirsch DOT de (Hans-Bernhard Broeker)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Plague of the slow 'blit' routine :)
Date:	22 Oct 1999 14:55:28 +0200
Organization:	RWTH Aachen, III. physikalisches Institut B
Lines:	24
Message-ID:	<7upms0$3c1@acp3bf.knirsch.de>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 991021191954 DOT 4851E-100000 AT is> <380F58BD DOT 9FDDC7CF AT connect DOT ab DOT ca>
NNTP-Posting-Host:	acp3bf.physik.rwth-aachen.de
X-Trace:	nets3.rz.RWTH-Aachen.DE 940596931 14303 137.226.32.75 (22 Oct 1999 12:55:31 GMT)
X-Complaints-To:	abuse AT rwth-aachen DOT de
NNTP-Posting-Date:	22 Oct 1999 12:55:31 GMT
X-Newsreader:	TIN [version 1.2 PL2]
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Tom Fjellstrom (tomcf AT connect DOT ab DOT ca) wrote:
[...]
> Because I want to call the same routine on any bitmap whether or not
> it's a regular bitmap, the screen, or a sub bitmap of the screen.

Excuse me repeating myself, but I think this point really needs some
stressing: you have a serious design problem, here, and there's no way
your choice of nearptr() vs. far*() methods will get you out of it.

Reading off screen memory, like you are planning to do, here, is
*extremely* inefficient. Shawn Hargreaves once gave more precise
numbers, IIRC, but in the essence, reading from screen memory is
usually about a factor of 10 or so slower than writing to it. Compared
to main memory access speed, the slowdown is even worse. So, if you
want it fast:

	Avoid reading from screen memory --- it's awfully SLOW

The usual solution is to do all the drawing, copying and whatnot in
main memory, alone, and only after that's complete, blast the whole
image to the screen, in one blit().
-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -