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]

[libove]

So, it's baaaaack. PDF-XChange v10.6.0 build 396 on my Windows 11 Pro Lenovo ThinkPad T16 Gen 2 notebook computer.
I'm scrolling through a PDF document (about Intel AMT) and some ways down as I'm skimming the document by hitting spacebar, a next press of the spacebar ... and nothing happens. I tap spacebar again - six times in a row, with approximately 1/2 second to 1 second between taps. No reply. 7th tap of the spacebar, responds again.
I can't reproduce the issue on-demand, but apparently it is still happening.
Any diagnostic data collection steps I can take next time it occurs, or that I must take in advance so that adequate logs are kept for collection right after the next time it happens?

[Daniel - PDF-XChange]

Hello, libove

I do not know of anything inbuilt to the software which would offer this, but I have checked with the dev team if perhaps a debug build would be available for you to use in such a scenario. My worry with that is debug builds tend to intentionally slow down many operations, which could either result in this issue happening when it normally wouldnt for you, or inversely, cause the issue to vanish, but you would be stuck using a build which operates at half capacity with a bunch of unnecessary logging enabled..

Seeing as you are the only one reporting this issue so far, without it being clearly attributed to wireless keyboard, other hardware, or some specialized third party interference, I am unsure how else to continue without testing such options.

(Reduced size here, as the below is more speculation on my part, I am not a specialist in whatever area of biology muscle memory falls into.. But with my hobbies, I am frequently re-training my muscle memory due to changes between applications I use on any given day. When I forget to do that, I run into issues in a similar vein every so often. Which leads to my theory, and how I would reason through the issue if I was encountering it myself.)

• Part of me still wonders if this is a case of human habit/muscle memory impacting your process. Sort of like when someone says "it's strange how you never think about breathing until someone suggests you consciously think about it"... (I apologize for using this particular example).
  
  Most applications that I know of, including web browsers, perform the first "scroll" on button "press" (instead of "release", like we do). You then have a fraction of a second before the windows "repeat keypress" feature kicks in and causes the page to be scrolled through rapidly due to multiple "presses" happening in sequence.
  
  That muscle memory leads us to expect the scrolling to happen on press, and often causes a subconscious "extended hold" of the spacebar for scrolling action (likely longer than the ~1/3 of a second mentioned before. The reason you could not observe the issue after we last spoke of it, could likely be because I mentioned the delay timing, and you were actively thinking about it a that time, leading to an increase in your press/release speed compared to a standard use cases.
  This is also happens in "repetitive actions" like when we are testing and pushing the button once every second, your body likes to get into a pattern. Your test of "1 second presses" convert into subconscious "1/2 second push, 1/2 second release", until you force yourself to press/release as fast as physically possible.
  
  Our active investigation of this, and the knowledge of the delay length while we do so could be why we are unable to reproduce the problem. We do not often do much "generic use/reading" of PDF documents. We typically do targeted investigations of numerous files, which leads to a different mindset, and different use habit than a typical user would have.

Kind regards,

[Willy Van Nuffel]

Maybe verify Keyboard Properties like Repeat delay and Repeat rate, via Control Panel > Keyboard ?
°

Windows 10 - Control Panel - Keyboard Properties.png

Myself, I can not reproduce the mentioned problem.

Kind regards.

[libove]

First, to Willy - good idea to check; I'm pretty sure the problem isn't coming from there:


Daniel, that's a great theory. In this case, I'm confident that my timing really was tap (quite quickly) wait (almost a full second), repeat. As an example, I set the "long press" time on my Android phone's touch keyboard to be shorter than average, to speed up my getting the alternative characters for each "key" on the on-screen keyboard (being that I type in three languages on the same keyboard setting, I frequently need alternate characters). So, I'm fairly attuned to those patterns. (And, in this case, since I'm aware of the odd situation, the instant the first spacebar didn't scroll, I became very attentive to what I was doing). On the seventh identical tap of the spacebar, it started scrolling normally again.

Regarding the resource cost of running the verbose-debug-enabled version, I'm fine with that. I can always uninstall the debug version and go back to the production release if it's an issue. Also, if it slows the system down, that might actually provoke the occurrence, which would give us the diagnostic logging we need. Or else it won't make a difference.
Anyway, I'm perfectly happy to give it a try, thanks.

[Daniel - PDF-XChange]

Hello, libove

Glad to hear it! I am still waiting for the Dev team's feedback on this, but I will keep in mind your are open to the possibility of a debug version if that topic comes up in their discussion.

And @Willy, thank you for the suggestion. I am sorry to hear that it didn't help, but it was definitely a good idea.

Kind regards,