Mail Archives: djgpp/2000/09/14/08:15:53
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.
- Raw text -