INKEY$ and graphics

[G Grant]

I'm getting sluggish response from the keyboard with INKEY$ when using graphics commands.

Even if all I do is simply plot random pixels, and nothing else, and check INKEY$ after each pixel to exit the program if a key is pressed, the response is very sluggish. The program will go through several more iterations of pixel plotting after pressing a key before exiting. And the longer I let the program run, the more sluggish the response. I'm making sure to use CONSOLE SET FOCUS before each INKEY$, in case the console loses focus due to a mouse click, but that makes no difference in responsiveness. And the REDRAW option doesn't seem to help here either. Not that it is needed for individual pixels, but with other, more complicated graphics, it speeds up the graphics drawing itself, but not the responsiveness of INKEY$.

Does anyone have any suggestions on how to work around this? Is there a better way to get immediate keyboard response on the fly while working with graphics?

Thanks very much.

[Guy Dombrowski]

Sluggish

You should try WAITKEY$ instead

[G Grant]

Well, it has to be on the fly, it can't stop and wait if no key has been pressed.

I'm new to windows programming, so there's probably something that I'm not understanding about threaded programming.

[Michael Mattias]

If your program is "doing something" after INKEY$ returns null ("it can't stop and wait...") and the performance is sluggish, your problem is NOT with your choice of INKEY$. You have something in your code which is taking too long to get back to that INKEY$ statement to check again.

In this case, I'd say your design is , well, um, let's call it "non-optimal." You normally would not want to be drawing the screen a pixel at a time, because that WILL take forever.

But....you can try testing INSTAT instead of using INKEY$. INSTAT just checks if there is a keystroke you can pick up without the need to actually return a null string into your variable.

Also: if you are new to Windows programming, I will guarantee there is something you're not understanding about [multi]-threaded programs.. assuming we are in fact talking about the same thing.. that is, a program in which you are using the THREAD CREATE statement.




MCM

[G Grant]

There's really not a lot to optimize in my test code (unless I'm overlooking something about the way programs under windows work).
Here is some test code to show the problem. All it does is draw a rotating line in a loop. Throughout the loop, INKEY$ is checked to see if a key has been pressed, and if so, end the program.
Even with this simple code, the longer you wait to press a key, the longer it takes for INKEY$ to respond. INSTAT gives the same result.
What is it about INKEY$, graphics, and PBCC that I'm not understanding?

FUNCTION PBMAIN () AS LONG
    radian# = .017453293
    radius# = 500
    xcenter# = 500
    ycenter# = 500

    CONSOLE SET SCREEN 1, 19
    CONSOLE SET LOC -1000, -1000
 
    GRAPHIC WINDOW "", 50, 50, 1000, 1000 TO MyWindow???
    GRAPHIC ATTACH MyWindow???, 0, REDRAW
    GRAPHIC COLOR RGB(0, 0, 255), RGB(0, 255, 0)

 
    linecolor& = RGB(255, 0, 0)
    DO
        FOR angle# = 0 TO 359 STEP .05
            GRAPHIC CLEAR
            
            x# = xcenter# + radius# * SIN(angle# * radian#)
            y# = ycenter# - radius# * COS(angle# * radian#)
            GRAPHIC LINE (xcenter#, ycenter#) - (x#, y#), linecolor&
            GRAPHIC REDRAW
            CONSOLE SET FOCUS
            IF INKEY$ <> "" THEN END
        NEXT
    LOOP
    GRAPHIC WINDOW END
END FUNCTION

[Mel Bishop]

What kind of machine are you using this on? I tested your code on a Dell 2.4 Ghz machine and, even after leaving it run for 5 minutes, the program aborts, Johnny on the spot, when I press a key.

[G Grant]

Hmm, well, that helps. Thank you VERY much for testing and getting back to me.

I'm on an Intel Pentium 3.0 Ghz, WinXP Pro, 2 gig of RAM, ATI X1950 Pro AGP 512 meg.

So it looks like maybe something is running in the background on my machine that might be causing this issue.
Or maybe a windows setting?

Running on my taskbar are Daemon tools, Virtual Drive Pro, ATI tray tools with video temp monitor, ICQ, and monitor calibration wizard. I will try shutting them all down and see what happens.

Can anyone else test and verify that it responds instantly?


Welp, I stopped all those processes, and it made no difference, so it wasn't that. SOMETHING has to be different on my machine from Mel's that's making it work differently.

[Mel Bishop]

>>>...something is running in the background...<<<

Bring up Task Manager (Ctl-Alt-Del) and see if one or more processes is chewing up your CPU percentage.

[G Grant]

Nothing. Several processes running, but all at 0% usage. System Idle at 99%.

[Gary Barnes]

Hi,
I tested the code also and keypresses are instantly detected.
P4 3.2Ghz with 2Gb Ram, XP SP2
Regards

[G Grant]

Ok, sounds like the problem is definitely on my PC.

Thank you both for verifying this for me. At least now I know where to look for the problem.


Thanks all.

[Mel Bishop]

>>>...System Idle at 99%...<<<
On my system, the process bounces between the high 80's and low 90's in CPU usage with the idle process at zero.

I can't think, for the life of me, what could be going on in your box to cause a 99% idle time.

[keith shelton]

Using xp pro on an amd x2 4400 system with 2gb ram, the response is instant.
KS

[Paul Dixon]

I see the same problem of sluggish response compounded by my PC crashing and losing the video card driver which it still can't find even after a reboot!
The PC doesn't just become unresponsive, it becomes unuseable with not even the Task Manager being able to function properly.
A different version of the compiler (PBCC4.01) does work.

I'll look into it further but I'm have trouble tracking the problem down as the PC has a tendancy to crash every time I try out the program.

Paul.

[Michael Mattias]

PB/CC 4.03.. compiles and runs clean,instant stop on keypress.
Windows XP/SP2 all updates.

[G Grant]

I see the same problem of sluggish response compounded by my PC crashing and losing the video card driver which it still can't find even after a reboot!
The PC doesn't just become unresponsive, it becomes unuseable with not even the Task Manager being able to function properly.
A different version of the compiler (PBCC4.01) does work.

I'll look into it further but I'm have trouble tracking the problem down as the PC has a tendancy to crash every time I try out the program.

Paul.

Hmm, that is very strange, especially for such a simple, straightforward program. This might be video driver related, which would explain why it works correctly on some PCs, but not on others. I will try uninstalling my driver and just run a generic windows driver and see what happens.

What video card and driver do you have?

[Paul Dixon]

I have an ATI ASUS Radeon A9200SE but I don't think that's the problem.

Which compiler version are you using? (Compile the program and it'll tell you).
With PBCC4.01 your program runs fine here.

I'm sure there was an issue some time ago with the graphics being slow because after each graphic operation the remainder of the timeslice was relinquished so a program could only perform 1 graphic operation per CPU timeslice even though this meant wasting 99% of the available processing during that time slice. Effectively, there was a built in SLEEP 1 after each operation.
PB introduced some change which corrected this by not relinquishing any timeslice and it caused graphics to hog the CPU so much that nothing else got a look in. That's what appears to be happening now.
It was fixed properly by PBCC4.01.

Paul.

[G Grant]

I'm using PBCC 4.04, and an ATI card also.

I tried using just the windows generic driver, and the program responded instantly to a key press. BUT, the graphics were extremely slow, as would be expected, so that's not even an option.
To me, what this seems to indicate is that there's some kind of buffering going on in the video driver, and the buffered graphics have to finish rendering before console input can be read? Just guessing here, but it seems like something along those lines.

But if, as you say, this was an issue in the past, then maybe this is a known issue that slipped back in, and can be fixed in an update.

[Paul Dixon]

G,
maybe it is something to do with the ATI card. I ran your original program on a different machine with Intel graphics and it worked in all version of PBCC I have from 4.01 upwards.
Strange that my PC runs fine with everything except your program. I'd have thought any problems would have shown up well before now.
Maybe I should try updating the driver and see what hapens.

Paul.

[Guy Dombrowski]

System idle at 99%

Well,

I have a AMD X2-6000 with 2 gb DDR 800 and my
VGA card is a 8800GT with 512 but my 2 CPU are showing
50% to 60% usage ???

Same thing with INSTAT

If you add a SLEEP before the inkey$, the usage drop a lot

But it stopped nicely all the time