On 22 Aug 2007, at 18:24, Evgeniy Ivanov wrote:
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
It is because you do not redirect the line drawing directly to SDL,
but instead use the default line drawing routines. Those are indeed
very slow, because they call a procedural variable (directputpixel)
for each pixel which has to be drawn). And directputpixel then calls
through to SDL, which every time must recalculate the pixel position
on the screen (instead of just adding 1 to the horizontal or vertical
coordinate in case of horizontal/vertical line drawing).
Hm... I really forgot to hook Line (but wrote the routine). But
HLine and
VLine are hooked and the speed problem is in the Bar function, it
has such
code:
for y:=y1 to y2 do
Hline(x1,x2,y);
HLine is hooked and works quickly. But it locks the screen every
time it is
executed (but calls DirectPutPixel without locking (that's why it
is fast):
procedure sdlgraph_HLine(x,x2,y: smallint);
var
temp:DefPixelProc;
begin
temp:=DirectPutPixel;
DirectPutPixel:[EMAIL PROTECTED]; // It doesn't lock the
screen as
sdlgraph_DirectPutPixel. It's quick.
No, it is still slow. You indeed do not have locking overhead, but
you are still calling nonBuf_DirectPutPixel via a procvar for each
pixel which has to be drawn (from hlinedefault). That is still very
slow.
Bar3D's speed is fine if you have a fast hline implementation (like
for e.g. go32v2 in most modes).
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
