[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
slow.
Bar3D's speed is fine if you have a fast hline implementation (like
for e.g. go32v2 in most modes).
Jonas
More information about the fpc-devel
mailing list