Sluggish system with REDRAW and GRAPHIC CLEAR

[G Grant]

I stumbled upon this problem by accident when I forgot to put in a REDRAW inside a loop, resulting in very sluggish system response.

I appears that if you put a GRAPHIC CLEAR statement inside a loop with the REDRAW option (writing to the graphic buffer instead of the screen), and then don't actually REDRAW the screen each iteration, the system becomes VERY sluggish. However, if you REDRAW each iteration, everything works fine.

Here is some example code to show the problem:

#COMPILE EXE

FUNCTION PBMAIN () AS LONG

    DESKTOP GET CLIENT TO w&, h&
    background??? = RGB(0, 0, 255)

    GRAPHIC WINDOW "", 0, 0, w&, h& TO MyWindow???
    GRAPHIC ATTACH MyWindow???, 0, REDRAW

    DO
        GRAPHIC CLEAR background???
        'GRAPHIC REDRAW
        GRAPHIC INKEY$ TO a$
    LOOP UNTIL a$ <> ""

END FUNCTION

With the GRAPHIC REDRAW REMmed out, the GRAPHIC INKEY$ function is VERY sluggish, but if you enable GRAPHIC REDRAW, all is fine.

It should work either way, as all that is happening without the GRAPHIC REDRAW is that the off screen buffer is being overwritten over and over again, nothing more. Or at least, that is what SHOULD be happening. But apparently something else is going on with the buffer when it is not transferred after being fully written, and is then written again.

Anyone else get this result?

[Chris Boss]

I am going to take a wild guess at this one, since I don't work with the PB graphic commands, but I think I know what it may be.

It doesn't matter whether you are using a PB graphic window (or control) or any other graphic window, the situation is the same.

When a window is updated there are two ways to update it:

(1) Redraw the windows image (or buffer) and force an immediate redraw. Basically this means Windows will generate an immediate WM_PAINT being sent directly to the windows window procedure.

(2) Invalidate an area (rectangle or region) for the window. This means Windows generates the WM_PAINT message and it is posted to the applications message que. Many may not realize this, but normal WM_PAINT messages are sent to the message que and are processed only when no other messages are pending in the que. The WM_PAINT messages will then be forwarded through the message loop to the windows window procedure. Only then does the window actually redraw itself.

The problem with posted WM_PAINT messages (normal way they are generated) is that they can actually build up faster than the message loop processes them.

If you have code that loops and generates WM_PAINT or you try to generate repeated WM_PAINTs in a Thread (which loops) and the WM_PAINTs are posted (meaning you invalidate regions/rectangles rather than immediately force a redraw), the WM_PAINTs will generate faster than the system can process them and it bogs everything down.

I have experienced this when working with Threads which draw graphics at high frame rates.

So your problem is not a problem at all.

Simply put, when executing repeated graphic window draws at a fast rate in a loop, you must force the graphic window to update immediately within each iteration of the loop, otherwise you will experience this same problem.

[G Grant]

Ah, that makes sense, thanks Chris.