[fpc-devel] sdlgraph, pre-alpha

Jonas Maebe jonas.maebe at elis.ugent.be
Wed Aug 22 18:49:56 CEST 2007

On 22 Aug 2007, at 18:24, Evgeniy Ivanov wrote:

> 2007/8/22, Jonas Maebe <jonas.maebe at elis.ugent.be>:
>> 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:=@nonBuf_DirectPutPixel;   // 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  

Bar3D's speed is fine if you have a fast hline implementation (like  
for e.g. go32v2 in most modes).


More information about the fpc-devel mailing list