Keyboard delay under NT OS
Scott Coffey
XP. I've noticed that there is a slight (few milliseconds) delay when
entering data via the keyboard (such as entering an item number) under
XP that was not there under 98. I see this both when simply copying
an existing Clipper app over from the 98 machine and running it under
XP or when recompiling the app on the XP machine. Any idea what is
causing this slight delay on keyboard input?
Norman Perelson
See "My application is hogging the CPU, what can I do?" in Dave
Pearson's "FAQ: Very Frequently Asked Questions", last posted to this NG
on 20 May.
--
Norman Perelson
http://shoso.com
N:dlzc D:aol T:com (dlzc)
"Scott Coffey" <no...@noemail.com> wrote in message
news:h3oj34te242iu0254...@4ax.com...
To add a little more to Norman's response, the routines to be
incorporated into your code for NT/2K/XP needs to be a little
different for yielding timeslices, than you could "get away with"
in 95/98/ME. Klas has a good routine, if you did not already
know about it.
David A. Smith
Scott Coffey
wrote:
Thanks for the replies.
Oddly enough, it's the yielding of timeslices that is causing the
problem. If I do nothing toward addressing the issue of yielding
timeslices, the keyboard is slightly more responsive. When I add code
(either via FT_OnIdle or blicpurel) to yield timeslices, the delay is
very slight but still noticeable. I'm guessing that when I add code
to yield timeslices back to the OS, then the program is in more of a
'sleep' state and thereby isn't as responsive to keys being pressed?
It isn't a show-stopper... just something that I noticed and thought
maybe there was some sort of environment variable or something that I
was missing. The application can still keep up with data entered via
a barcode scanner, so it's certainly fast enough to keep up with
manually keyed data.
Klas Engwall
>Oddly enough, it's the yielding of timeslices that is causing the
>problem. If I do nothing toward addressing the issue of yielding
>timeslices, the keyboard is slightly more responsive. When I add code
>(either via FT_OnIdle or blicpurel) to yield timeslices, the delay is
>very slight but still noticeable. I'm guessing that when I add code
>to yield timeslices back to the OS, then the program is in more of a
>'sleep' state and thereby isn't as responsive to keys being pressed?
Then it is probably a good idea to try to tweak the settings for the
time slice yielding. If you use FT_IAmIdle() you could try to decrease
the nIntensity argument and see if that helps. What does the code
where you launch the time slice solution look like now?
Regards,
Klas
-------
klas dot engwall at engwall dot com
http://www.engwall.com/clipper/
The LFN Library for Clipper
The LanMan Library for Clipper
The NFPAT1A Timeslice release patch for the Nanforum Toolkit
Scott Coffey
Engwall) wrote:
>Scott,
>
>>Oddly enough, it's the yielding of timeslices that is causing the
>>problem. If I do nothing toward addressing the issue of yielding
>>timeslices, the keyboard is slightly more responsive. When I add code
>>(either via FT_OnIdle or blicpurel) to yield timeslices, the delay is
>>very slight but still noticeable. I'm guessing that when I add code
>>to yield timeslices back to the OS, then the program is in more of a
>>'sleep' state and thereby isn't as responsive to keys being pressed?
>
>Then it is probably a good idea to try to tweak the settings for the
>time slice yielding. If you use FT_IAmIdle() you could try to decrease
>the nIntensity argument and see if that helps. What does the code
>where you launch the time slice solution look like now?
I did tweak it a bit and I now have it at an acceptable level. It's
still not as responsive as typing directly into a "dos" box but only
the most anal among us would care about the difference. <g>
Klas Engwall
>I did tweak it a bit and I now have it at an acceptable level. It's
>still not as responsive as typing directly into a "dos" box but only
>the most anal among us would care about the difference. <g>
That sounds like a four stars of five rating <g>. What did you set the
intensity to finally?
Scott Coffey
wrote:
>I'm in the process of moving Clipper apps from Windows 98 machines to
OK, I just found something interesting. If I run my Clipper
application in full screen mode, the keyboard input is much more
responsive than when running in a window. I didn't pick up on this
before because I do almost all of my development work in a window. The
end user always runs full screen.
Is this a Clipper issue or a video issue?
N:dlzc D:aol T:com (dlzc)
"Scott Coffey" <no...@noemail.com> wrote in message
news:5roq54dpcjge6tp2i...@4ax.com...
...
> OK, I just found something interesting. If I
> run my Clipper application in full screen mode,
> the keyboard input is much more responsive
> than when running in a window. I didn't pick
> up on this before because I do almost all of
> my development work in a window. The end
> user always runs full screen.
>
> Is this a Clipper issue or a video issue?
Neither. It is a WinDoze issue, where more timeslices (or more
frequent) are allowed for full screen apps, rather than polling
all "fourty" processes on a given machine. If you are windowed,
WinDoze thinks you may be interested in something outside the
foreground app window, so it polls "everything".
David A. Smith
Klas Engwall
>OK, I just found something interesting. If I run my Clipper
>application in full screen mode, the keyboard input is much more
>responsive than when running in a window. I didn't pick up on this
>before because I do almost all of my development work in a window. The
>end user always runs full screen.
>
>Is this a Clipper issue or a video issue?
IMHO, that is almost certainly caused by the OS and the NTVDM. And I
suppose it has something to do with the extra time it takes to render
text in the GUI compared to text mode.
On my ancient NT4 machine (which is my favorite work horse and far
more reliable than all my XP machines together) I use the 1986 Norton
Editor windowed and full screen interchangeably, and there is a
significant difference in how it reacts to keyboard commands. Even
simple things like F3 S Y to save and continue must be typed slowly in
windowed mode or the editor will stop and ask for confirmation ("Save
file (Y or N)?") because the Y has been lost. I never have those
problems when running it full screen.
Scott Coffey
wrote:
Thanks for the replies David and Klas.
The end users will be running in full screen so there's no problem.
I'm the only one that will have to 'suffer'. :)
Norman Perelson
I have many users running a Clipper app and there is no difference in
keyboard response whether running in full screen or a window. I am
compiling with Clipper 5.3b and linking with Blinker 7 in 'real' mode
(heavily overlaid). For taming the CPU usage I use AutYield which is
included in oslib.
I suspect that the latency that you describe is caused by the graphics
hardware or graphics driver in your computer. I cannot see how it could
be a Clipper issue per se considering that full-screen mode works all right.
Scott Coffey
Thanks for the feedback, but my tendency is to agree with the
explanation given by David and Klas. I've tried this on several
different machines including stock IBM Netvista boxes as well as my
fairly exotic self-built gaming rig. I've also tried it under both XP
and W2K and in every case the windowed version exhibits slower
keyboard response than full screen. It's not a big difference mind
you, but noticeable nonetheless.
Of course I could be missing a damn switch somewhere.... ;-)
Scott Coffey
<nor...@shoso.co.za> wrote:
>For taming the CPU usage I use AutYield which is included in oslib.
Forgot to ask... Since you're using Blinker 7, why not use
blicpurel()?
frank van nuffel
"Scott Coffey" wrote in message
news:dc8764hagi037fqk7...@4ax.com...
> Of course I could be missing a damn switch somewhere.... ;-)
Just fyi, http://www.tamedos.com is a utility which provides external
switches to ntvdm console apps, tweaking performance, among others keyboard
speed; it is a great utility but imho the docs should provide more extended
information. I'm just no certain if it will help, but there's a trial
download available.
regards,
frank