On Feb 18, 2007, at 15:51 , Herbert König wrote:

> Hello,
>
> using BitBlt for speed I draw some 15.000 white rectangles on a Morph.
> Each is 4x4 pixels.
>
> On my slow computer I get 480ms for the following method:
>
> testDrawWhiteRects
>         "just try if the white rectangles are drawn correctly"
>
>         | bb |
>         bb := BitBlt new.
>         bb setDestForm: Display.
>         bb width: dotSize ; height: dotSize .
>         bb fillColor: Color white; combinationRule: Form paint.
>         rectangleCoords do: [:koords| bb destX: koords x; destY:  
> koords y; copyBits.]

Wouldn't "Form over" be sufficient?

> If I comment out the actual transfer (the copyBits) the result is only
> 25ms.
>
> I use a Display depth of 32, no difference if I change between big and
> little endian and my Win also uses 32 bits display depth.

Try not drawing to Display but to a temporary form, and then blt this  
one.

> Tried with 3.7 and 3.9 VM. Also nearly no difference between OpenGL
> and Direct3D.

BitBlt has nothing to do with OpenGL or D3D.

> On a fast computer (1.86GHz Pentium M) results aren't much better (10
> and 270ms).
>
> Is this to be expected, or am I doing something wrong? We have
> Ballon3D which promises real time movement and I guess it finally
> relies on BitBlt. So I expected much better performance.

Balloon3D does have a software rasterizer as well as an hw- 
accelerated renderer. But drawing 15,000 separate rectangles even in  
C and OpenGL would be exactly speedy. You would have to wrap your  
drawing algorithm around the way the hw wants it.

What are you actually trying to achieve? It's probably much more  
efficient to update a single form and then enlarge it by 4 using  
warpblt.

Also, the Kedama Plugin has primitives for drawing large numbers of  
particles, if that is what you're after.

- Bert -