Polygon strange variation is drawing speeds

[Wampus]

I don't know if this is a bug or not. When I run the code included in this post I get two very different times for drawing 30000 identical sets of polygons. They differ in bizarre ways. If you are getting a similar result as me when you run the included code the results should be something like this:

Test 1
10000 of the left polygons in milliseconds: 2925
10000 of the right polygons in milliseconds: 9

Test 2
10000 of the left polygons in milliseconds: 5
10000 of the right polygons in milliseconds: 9304

and then a repeat of the tests shows that each 30000 round of polygons only takes 1 to 10 milliseconds?!?

What is happening here? This must be my graphics card optimising the drawing of these polygons?

Code (glbasic) Select Expand

LOADSPRITE "test.png", 2

GLOBAL time1, time2, time3, time4

// Test 1 for GETTIMERALL() bug

WHILE KEY(01) = FALSE

time1=GETTIMERALL()
STARTPOLY 2,1
FOR p = 1 TO 30000

POLYVECTOR 64, 64, 0, 0, RGB(255, 255, 255)
POLYVECTOR 64, 128, 0, 64, RGB(255, 255, 255)
POLYVECTOR 128, 128, 64, 64, RGB(255, 255, 255)
POLYVECTOR 128, 128, 64, 64, RGB(255, 255, 255)
POLYVECTOR 128, 64, 64, 0, RGB(255, 255, 255)
POLYVECTOR 64, 64, 0, 0, RGB(255, 255, 255)

NEXT
ENDPOLY
time2=GETTIMERALL()

time3=GETTIMERALL()
STARTPOLY 2,1
FOR p = 1 TO 30000

POLYVECTOR 192, 64, 0, 0, RGB(255, 255, 255)
POLYVECTOR 192, 128, 0, 64, RGB(255, 255, 255)
POLYVECTOR 256, 128, 64, 64, RGB(255, 255, 255)
POLYVECTOR 256, 128, 64, 64, RGB(255, 255, 255)
POLYVECTOR 256, 64, 64, 0, RGB(255, 255, 255)
POLYVECTOR 192, 64, 0, 0, RGB(255, 255, 255)

NEXT
ENDPOLY
time4=GETTIMERALL()

PRINT "Test 1", 0, 140

PRINT "30000 of the left polygons in milliseconds: "+INTEGER(time2-time1), 0, 160

PRINT "30000 of the right polygons in milliseconds: "+INTEGER(time4-time3), 0, 180

PRINT "Press mouse button to continue", 0, 200

PRINT "time1: "+time1, 0, 0
PRINT "time2: "+time2, 0, 10
PRINT "time3: "+time3, 0, 20
PRINT "time4: "+time4, 0, 30

SHOWSCREEN

MOUSEWAIT



// Test 2 for GETTIMERALL() bug



STARTPOLY 2,1

time1=GETTIMERALL()
FOR p = 1 TO 30000
POLYVECTOR 64, 64, 0, 0, RGB(255, 255, 255)
POLYVECTOR 64, 128, 0, 64, RGB(255, 255, 255)
POLYVECTOR 128, 128, 64, 64, RGB(255, 255, 255)
POLYVECTOR 128, 128, 64, 64, RGB(255, 255, 255)
POLYVECTOR 128, 64, 64, 0, RGB(255, 255, 255)
POLYVECTOR 64, 64, 0, 0, RGB(255, 255, 255)
NEXT
time2=GETTIMERALL()

time3=GETTIMERALL()
FOR p = 1 TO 30000
POLYVECTOR 192, 64, 0, 0, RGB(255, 255, 255)
POLYVECTOR 192, 128, 0, 64, RGB(255, 255, 255)
POLYVECTOR 256, 128, 64, 64, RGB(255, 255, 255)
POLYVECTOR 256, 128, 64, 64, RGB(255, 255, 255)
POLYVECTOR 256, 64, 64, 0, RGB(255, 255, 255)
POLYVECTOR 192, 64, 0, 0, RGB(255, 255, 255)
NEXT
time4=GETTIMERALL()

ENDPOLY

PRINT "Test 2", 0, 140

PRINT "30000 of the left polygons in milliseconds: "+INTEGER(time2-time1), 0, 160

PRINT "30000 of the right polygons in milliseconds: "+INTEGER(time4-time3), 0, 180

PRINT "Press mouse button to continue", 0, 200

PRINT "time1: "+time1, 0, 0
PRINT "time2: "+time2, 0, 10
PRINT "time3: "+time3, 0, 20
PRINT "time4: "+time4, 0, 30

SHOWSCREEN

MOUSEWAIT

WEND

[Kitty Hello]

the first set is slower, because I internally have to allocate a buffer for the drawn vertices, that grows with your drawing. At the 2nd run the memory is already there.

[Wampus]

That makes sense. Internal allocation of memory. I did some more tests to see how that works. Now I see that memory is added dynamically whenever the upper ceiling on the number of polygons drawn between STARTPOLY and ENDPOLY is raised.