From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: What is faster as memcpy???
Date: 14 Sep 2000 12:12:18 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 27
Message-ID: <8pqfb2$hmk$1@nets3.rz.RWTH-Aachen.DE>
References: <CCPv5.8958$l6 DOT 494172 AT zwoll1 DOT home DOT nl>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 968933538 18132 137.226.32.75 (14 Sep 2000 12:12:18 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 14 Sep 2000 12:12:18 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

To answer the 'Subject:' question straight away: nothing, generally.
Not with a memcpy() as clever as the one used by DJGPP.

Riox92 <t-bos AT home DOT nl> wrote:
> Its for a VESA2.0 24bit LFB Switch routine.

> Now i use memcpy. on a screen of 640*480*24bit screen.
> But on little objects dots the switch looks to slow.. 

This is really a rather unclear way of expressing what happens. *What*
exactly do you do with memcpy, here? And how slow is 'too slow', in
numbers? Typically, you almost certainly should not be using memcpy()
to copy single pixels. That would be much more efficiently done via
direct access to an array. memcpy() is meant for at least moderately
large blocks of memory being sent around, not for single 'dots'.

Also be aware that, LFB mode or not, access speed of the graphics
card's memory is still a big lot slower than your typical main RAM or
the caches RAM of the CPU. Even more so if you ever read from graphics
memory. This is the reason why it's usually better to do all the
manipulation operations on a RAM buffer, and only after completion of
it, blast the whole thing to the framebuffer in a single large
memcpy().

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.