spacebar scrolling .. stutters?

[libove]

In recent PDF-XChange versions (10.6 and 10.5 at least, maybe also 10.4 and/or before), pressing the spacebar to scroll down by about one page occasionally .. stutters. That is:

spacebar (scrolls down about a page)
spacebar (scrolls down about a page)
spacebar (nothing)
spacebar (nothing)
spacebar (nothing)
spacebar (nothing)
spacebar (nothing)
spacebar (nothing)
but then suddenly without me doing anything different:
spacebar (scrolls down about a page)

insert :head-scratch-emoji here ...

I note also that the Page Down key always works reliably. Even if spacebar is presently stuttering, Page Down will always scroll down by about a page.

Has anyone else seen this/ any explanations on offer?

thanks,
-Jay

[Daniel - PDF-XChange]

Hello, libove

We spoke a bit over email, but I do not want to push this off by the wayside. If any other users here on the forums have experienced the same, we would appreciate a video, with some graphic elements showcasing when the spacebar is pushed/released, so we can try to replicate the issue on this end.

So far, the closest we have come to replicating is, is with a brief delay prior to release of the spacebar. This is expected, however, perhaps the timer is too short, and so the team is looking at tweaking that timing slightly in the future.

If anyone else is able to reproduce this issue with a very quick press/release (no delay or hold at all), please do let us know!

Kind regards,

[libove]

Thanks Dan. Could you explain a bit more please, about the "brief delay prior to release of the spacebar"?

Do you mean, PDF-XChange is designed to catch very rapid spacebar presses and not respond to all of them?
If so, there's a possibility that rather than this being anything that PDF-XChange is doing 'wrong' it might be an interaction with something that I began noticing in Windows a year or two ago:

It seems that something in how Windows systems process interrupts DE-prioritized keyboard input at certain times.
I see it in VLC missing arrow up/down keystrokes to change volume, in the loss of the first keystrokes upon hitting Ctrl+Alt+Del to unlock the computer before the password input field activates, in whatever window had input focus prior to hitting the Windows/Start key still getting the first few keystrokes before the Start menu and its Search bar start getting the input.

I've seen this on various systems, ranging from old and slow and overloaded, to new and so powerful that they never struggle with anything, which is why I believe it's a Windows input handler change, and not just an old, low-resource system getting overloaded.

How this might relate to PDF-XChange and the spacebar is that either there's something that happens when a new document is opened in PDF-XChange which puts Windows into this "deprioritize keyboard interrupts" mode, or/and something about that time which causes spacebar hits by the user to NOT be processed by Windows and handed to PDF-XChange in the rhythm with which the user tapped the spacebar, but instead to queue up two or more inputs such that PDF-XChange gets them all at once - triggering the "protect the user from accidentally holding down the key" feature.

Let's see if this jogs anything for anyone, and if/when I'm able to actually demonstrate it, I'll try to capture a video as requested.
-Jay

[Daniel - PDF-XChange]

Hello, libove

I am not certain of the specific timing, but what you describe may play a factor, in practice, spacebar "scrolling" is a two step process. On the keypress-down the action is "accepted" and on "release" within a predetermined timeframe (In my testing, it seems to be around, possibly under 1/3 of a second), the action is executed.

This fits twofold into what you mentioned:
- If you hold the spacebar for tool long, the Editor assumes you have hesitated, and do not want to scroll, so it cancels the action.
- If either the press, or release signal is delayed, or even never received, the editor would either revert to the above logic, or be unaware of what to do with the single input it received.

I have to admit, this is the first I am hearing about such a "feature" in windows for those keyboards, and if it is real, I am confused as to why such a function even exists in the first place. The way you described it sounds like they are emulating wireless interference, which... has never been something that anyone would want... (Speaking of which, are your keyboards wireless perchance, have you tried wired alternatives just in case?)

There is also of course the possibility that this is a simply case of device age. The spacebar is one of the most commonly "first broken" keys across most generalized use cases. It may be that the physical contact is dying. Though admittedly it would be quite strange, but not impossible for this to happen on multiple of your keyboards. Do you have a backup keyboard anywhere, that you can test with?

Kind regards,

[libove]

I agree completely - what I've seen in recent years about the change in the way that Windows handles (I think) keyboard interrupts would definitely fit into my definition of "bug", not "feature".
I've seen it on several systems of various ages and manufacture:
- two different Lenovo ThinkPads' built-in keyboards,
- two different Unicomp keyboards [Unicomp are the inheritors of the IBM "machine gun clack" buckling spring Model M keyboard, basically indestructible], and
- one or two generic cheap keyboards - okay, actually, one of these isn't generic or cheap at all, it's a high-end backlit programmable keyboard)
(All of these keyboards are wired).
So, I'm confident that the effect is coming from something in Windows - or in Windows' USB drivers on modern hardware - rather than in the keyboards themselves.
It's only a theory.

Grr, of course, I still now can't reproduce the problem in PDF-XChange .
Now that you've described the "if spacebar is held down, don't move" feature, I can 100% reliably reproduce *that* expected behaviour.
And I'm confident that's not what's happening in the case that I'm reporting (unless, of course, Windows/USB/drivers/interrupts, as theorized above, is changing how long Windows' intermediation of the keyboard actions look to PDF-XChange vs. how long phsyically I actually held down the spacebar).

So, I'll keep trying to figure out more specifically when it happens/ how to reproduce it, so I can show you.
thanks,
Jay

[magicpq]

I'd like to contribute the following to this discussion:
Firstly: I've observed something similar - Windows swallows the first keystroke on wireless keyboards (BT or RF). I haven't observed this phenomenon with USB keyboards or built-in, except when some sort of energy-saving is involved.
Regarding a specific observation with the spacebar: Releasing the spacebar within about 1/10th of a second triggers a form feed, holding it down for longer doesn't. In practice, this doesn't bother me. I simply hammer the spacebar until I get to the desired page. For longer sections, I hold down Page DN, and this key behaves as expected (continious scroll) or I use the mouse.
In addition: I work on a terminal server. There, latency sometimes occurs, which obviously leads to the effect that spacebar release isn't recognized immediately. It don't mind, but after this post, I think I know why it happens.
If you're typing continuously, it's not noticeable.
In summary: I can confirm the effect, but it doesn't bother me too much.

Regards, Peter

[libove]

Thanks magipq,
All of your observations are consistent with wireless, power save, and PDF-XChange's if-the-spacebar-is-held-down-"too long" behaviors.
The issue I occasionally encounter is always with wired keyboards, and never with the spacebar being physically held down long, and can cause multiple spacebar taps to be ignored. So, it's some different, as-yet undiagnosed issue.
(Of course, Murphy's Law, since I opened this thread, I've been unable to reproduce the problem ).
-Jay

I'd like to contribute the following to this discussion:
Firstly: I've observed something similar - Windows swallows the first keystroke on wireless keyboards (BT or RF). I haven't observed this phenomenon with USB keyboards or built-in, except when some sort of energy-saving is involved.
Regarding a specific observation with the spacebar: Releasing the spacebar within about 1/10th of a second triggers a form feed, holding it down for longer doesn't. In practice, this doesn't bother me. I simply hammer the spacebar until I get to the desired page. For longer sections, I hold down Page DN, and this key behaves as expected (continious scroll) or I use the mouse.
In addition: I work on a terminal server. There, latency sometimes occurs, which obviously leads to the effect that spacebar release isn't recognized immediately. It don't mind, but after this post, I think I know why it happens.
If you're typing continuously, it's not noticeable.
In summary: I can confirm the effect, but it doesn't bother me too much.

Regards, Peter

[Stefan - PDF-XChange]

Hello libove,

Maybe you updated to build 396 and that's why the behaviour changed for you?
If the issue is no longer there - I'd say let's leave it as is?

Kind regards,
Stefan

[libove]

Hmm. I checked, I updated to .396 six days ago, and I'm fairly sure that the spacebar-ignored thing happened more recently :-/
But, it would be nice if I'm wrong, wouldn't it

Anything specific in the .396 changelog to suggest it might have addressed something like this?

Hello libove,

Maybe you updated to build 396 and that's why the behaviour changed for you?
If the issue is no longer there - I'd say let's leave it as is?

Kind regards,
Stefan

[Stefan - PDF-XChange]

Hello libove,

We do not mention all the minor tweaks and adjustment as the lists of fixes would then be way too long but you can see the changes and fixes we listed here:
https://www.pdf-xchange.com/product/pdf ... or/history


Kind regards,
Stefan

[libove]

Dang. And I thought that PDF-XChange's changelog was already about the most complete changelog offered by anyone (except for Lineage OS). I'd actually like an expanded "all the minor tweaks and adjustments" version of the changelog to be available (as an extra "click here to expand all the rest" kind of option).
To be very clear: KUDOS to Tracker Software for actually having a pretty complete changelog!

FWIW, I don't see anything in the published .396 changelog that looks like it would be related to the issue under discussion in this thread.
-Jay

Hello libove,

We do not mention all the minor tweaks and adjustment as the lists of fixes would then be way too long but you can see the changes and fixes we listed here:
https://www.pdf-xchange.com/product/pdf ... or/history


Kind regards,
Stefan

[Stefan - PDF-XChange]

Hello libove,

Such a list would take up too much developer time to implement, and I presume you would not want us (and our devs) to list all "fixed spelling here, or added coma there" kind of fixes - So we still try to make it as exhaustive as practical, but sometimes behaviour will change without the specific fix that caused this to be listed in that list.

Glad that you like how exhaustive it is so far, but it is not likely to get any more nitpicky (if that is even a word)!

Kind regards,
Stefan

[libove]

Indeed, corrections of misspellungs need not appera in the langechog.
But ideally all behavioral changes would.
Anyway, this remains one of the better managed and transparent pieces of software development I've seen in my 50 years of computer use.
Thank you,
-Jay

Hello libove,

Such a list would take up too much developer time to implement, and I presume you would not want us (and our devs) to list all "fixed spelling here, or added coma there" kind of fixes - So we still try to make it as exhaustive as practical, but sometimes behaviour will change without the specific fix that caused this to be listed in that list.

Glad that you like how exhaustive it is so far, but it is not likely to get any more nitpicky (if that is even a word)!

Kind regards,
Stefan

[Stefan - PDF-XChange]