Announcement

Collapse
No announcement yet.

speed of GRAPHIC BOX

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • speed of GRAPHIC BOX

    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.

    Code:
    ' 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

  • #2
    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
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      A big :doh: 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]
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        Originally posted by Michael Mattias View Post
        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!

        Comment


        • #5
          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.

          Comment


          • #6
            Originally posted by Paul Dixon View Post
            GRAPHIC ATTACH hGW, 0 ,REDRAW
            Thanks Paul!

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

            Comment


            • #7
              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.

              Comment


              • #8
                Originally posted by Paul Dixon View Post
                ...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.

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    Originally posted by Paul Dixon View Post
                    ...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.

                    Comment


                    • #11
                      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 !
                      Old QB45 Programmer

                      Comment


                      • #12
                        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/p...40&postcount=6

                        Comment


                        • #13
                          Originally posted by Paul Dixon View Post
                          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...

                          Comment

                          Working...
                          X