speed of GRAPHIC BOX

[Chris Holbrook]

After putting debug code into my application I realised that GRAPHIC BOX, which I was using to draw rectangles, was running not just slowly, but very slowly. I suspect that the cause is something in my PC's configuration, tiny amount of RAM, etc., but I did just wonder how fast it would run on "proper PCs", like yours!

Here's a little test routine which compiles with V5, and draws 1,000 boxes with GRAPHIC BOX, then 1,000 boxes with the API moveto/lineto functions. I'm getting timings of about 15secs and about 0secs, respectively. If your observations are much closer, then more iterations or a more accurate timebase would be a good plan.

' to compare speed of GRAPHIC BOX with that of API lineto
' Chris Holbrook Nov 2008
'
#COMPILE EXE
#DIM ALL
#INCLUDE ONCE "WIN32API.INC"
%iterations = 1000
FUNCTION PBMAIN () AS LONG
    LOCAL x, y, i, start AS LONG
    LOCAL hGW, hdc AS DWORD
    LOCAL skey AS STRING
    
    DESKTOP GET CLIENT TO x, y
    GRAPHIC WINDOW "", 0, 0, x, y TO hGW
    GRAPHIC ATTACH hGW, 0
    start = TIMER
    FOR i = 1 TO %iterations
        GRAPHIC BOX (100, 100) - (400, 400), 0, %BLACK, -2, 0
    NEXT
    GRAPHIC SET POS (100, 500)
    GRAPHIC PRINT STR$(%iterations) + " iterations using GRAPHIC BOX: " + FORMAT$(TIMER - start, "#.00") + " seconds"
    start = TIMER
    GRAPHIC GET DC TO hdc
    FOR i = 1 TO %iterations
        moveto hdc, 500, 100
        lineto hdc, 800, 100
        lineto hdc, 800, 400
        lineto hdc, 500, 400
        lineto hdc, 500, 100
    NEXT
    GRAPHIC SET POS (500, 500)
    GRAPHIC PRINT STR$(%iterations) + " iterations using lineto: " + FORMAT$(TIMER - start, "#.00") + " seconds"
    GRAPHIC WAITKEY$ TO skey
    GRAPHIC WINDOW END
    
END FUNCTION

[Michael Mattias]

Apples <> Oranges

Your GDI routine does not allow for the "corners", "color", "Fillcolor" or "fillstyle" options supported by the intrinsic GRAPHIC BOX statement.

If speed is a concern, maybe you should just stick with GDI when you don't need the additional options.

MCM

[Michael Mattias]

A big on me!

Apples <> Oranges, for sure.

Four "lineto" statements should be compared to four GRAPHIC LINE statements, not to GRAPHIC BOX.

Or, you can compare GRAPHIC BOX with CreatePen + FillRect [+ FrameRect ] [+ CreateBrush] + DeleteObject[s]

[Chris Holbrook]

Apples <> Oranges

Your GDI routine does not allow for the "corners", "color", "Fillcolor" or "fillstyle" options supported by the intrinsic GRAPHIC BOX statement.

Make what assumptions you like. I'm not making any, nor asking anyone to do so.

My question - see post#1, was: but I did just wonder how fast it would run on "proper PCs", like yours!

[Paul Dixon]

Chris,
first, don't assign the timer to a LONG on such short timings. TIMER returns an EXT and you're truncating the decimal part when assigning to a LONG which is introducing a significant error.

Second, The first loop is slower because when the screen is redrawn, the current time slice is given up. If you Ctrl-Alt-Del and check with Task Manager you'll see your code isn't using very much CPU time, it's just idling, waiting to get the next time slice which it then gives up almost immediately.
Try using:
GRAPHIC ATTACH hGW, 0 ,REDRAW
Then include a specific GRAPHIC REDRAW at the point in your code where you want the screen to be updated.

With those 2 modifications, your code runs both loops on my PC in 0.00secs.

Paul.

[Chris Holbrook]

GRAPHIC ATTACH hGW, 0 ,REDRAW

Thanks Paul!

So it wasn't the PC its was the programmer. How unusual!

[Paul Dixon]

Chris,
not entirely the programmers fault as I see no need for the compiler to give up that timeslice in those circumstances. Directly drawing via the API doesn't do that so it's not obvious to the programmer that the behaviour is to be expected.

Paul.

[Chris Holbrook]

...so it's not obvious to the programmer that the behaviour is to be expected.

...unless he reads the feckin' manual:

REDRAW
This option can provide a dramatic improvment in the execution speed of graphic statements, as it eliminates repetitive udates to the display. If this option is included, all drawing statements are buffered until a GRAPHIC REDRAW statement is executed, or the operating system chooses to update the target window. Without REDRAW, all graphical statements (Line, Box, Print, etc.) are performed immediately. However, in most cases, it's better to defer the display until a number of statements have been performed.

So I'll stick with mea culpa for the moment, which is not to say that GRAPHIC DRAW BOX needs to release its slice, unless it is for its own internal processes - as MCM pointed out, there is more going on in GRAPHIC BOX than line drawing. And thanks again for putting me on the right lines, I did not relish having to write even a subset of GRAPHIC BOX.

[Paul Dixon]

Chris,
that's not what I had in mind.
It's reasonable and understandable that the compiler offers you the option to update the window automatically after every graphic operation or to improve performance by waiting until told before updating the window. This is what the REDRAW option does.

The behaviour that I meant was not expected is that the graphic operation gives up the remainder of your program's timeslice in order to update the screen. It really ought to update the screen then return to your code for more and keep doing this until the OS ends your program's timeslice.

Paul.

[Chris Holbrook]

...that's not what I had in mind.
The behaviour that I meant was not expected is that the graphic operation gives up the remainder of your program's timeslice in order to update the screen. It really ought to update the screen then return to your code for more and keep doing this until the OS ends your program's timeslice.

Paul.

OK I understand, you consider that "as it eliminates repetitive udates" is not the same as "it gives away its timeslice so ANY operation, graphic or not, has to pay the price of not using the REDRAW option to GRAPHIC ATTACH". There is something to that, too. Maybe we will hear from PowerBasic on this one, you never can tell.

[Guy Dombrowski]

Wow,

I am always amazed with the depth of the kind of help we get here.

This is one of the reasons why I love PowerBasic !

[Paul Dixon]

Here's another way to update a graphic window so you don't have to bother doing it yourself but it still updates very often and without wasting CPU time.
It uses a thread (which gets its own timeslice) to update the window regulary so the display keeps updating. It doesn't matter that the thread's timeslice ends when the REDRAW is done as that's the only purpose of the thread so it has nothing else to do anyway.
The main program then just gets on with calculating and plotting and doesn't need to bother with updating the display.

https://www.powerbasic.com/support/pbforums/showpost.php?p=124840&postcount=6

[Chris Holbrook]

It uses a thread

Still not quite as good as using REDRAW when redrawing in response to mouse movement though, I suppose one could do both...