keyPressed() events get missed when another key is held

Architector_4 · July 13, 2019, 6:33am

EDIT: This seems to be related to key repeating that OS does when user holds a key for long enough, and how P2D/P3D engines handle that key repeating. My conclusion is seen here: keyPressed() events get missed when another key is held - #18 by Architector_4

Original post:
For some reason, sometimes, if I’m already holding another key, keyPressed() events go missing, and the function doesn’t trigger.
For example, take this code:

int n1,n2;
boolean held1, held2;

void setup(){size(100,100,P2D);}

void draw(){
  background(0);
  text(n1+" "+held1,0,15);
  text(n2+" "+held2,0,30);
}

void keyPressed(){
  if(key=='1'){ n1++; held1=true;}
  if(key=='2'){ n2++; held2=true;}
}
void keyReleased(){
  if(key=='1'){ n1--; held1=false;}
  if(key=='2'){ n2--; held2=false;}
}

In (at least my) ideal world, both values n1 and n2 should never be more than 1 or less than 0, as to every keyPressed() event there should be a corresponding keyReleased() event. However, very easily, I can end up with this:

I find this to be problematic, as I’d like my keyPressed() events to be triggered.
More facts:

If I’m pressing a single key without holding any other, events are never missed.
After I start holding the first key, only the first press of the second key may be missed - all subsequent presses of the second key are not missed.
This happens only on P2D and P3D engines, and doesn’t happen on JAVA2D engine (if I disable key repeating - else the keyPressed() gets activated very quickly a lot of time).
This happens with any pair of keys, not just keys 1 and 2 - arrow keys, J and ENTER, any.
This happens when I use both Processing by itself, and when I use Processing libraries in Eclipse.
This does not happen in any other non-Processing applications or games I’ve tried.
I’m running on Arch Linux with all packages updated, with Processing installed from Arch Linux repositories, package version 3.5.3-2, while Processing labels itself as “Processing 0269”

Here’s even a proof of concept (shoddily filmed from a phone; I’m sorry!) video:

Anyone have any ideas on how to get more reliable key press/release events on P2D and P3D engines? Is this a bug?

kll · July 13, 2019, 7:04am

-a- small mod

void setup() {
  size(100, 100, P3D);
  println("press key [1] and/or [2]");
}

void draw() {
  background(0);
  text("key [1] "+n1+" "+held1, 0, 15);
  text("key [2] "+n2+" "+held2, 0, 30);
}

-b- play

win7 /64bit
logitech K100 keyboard
test P2D P3D
also
Raspberry Pi 3B+ Raspbian Stretch
logitech K220 keyboard

but not see your problem here.

InferNova · July 13, 2019, 12:11pm

Hey There!

Definitely a bug which exists for you, but I haven’t observed your issue. But in any case you don’t need to use integer anymore do you ? You said it yourself in an ideal world you only are supposed to get 1 or 0 and you already have that… The boolean so you don’t really need the numbers to check if the keys are being pressed. But if you still want to use the numbers to observe if they are pressed.

You can always:

int n1, n2;
boolean held1, held2;

void setup() {
  size(100, 100, P2D);
}

void draw() {
  background(0);
  n1 = held1 ? 1 : 0;
  n2 = held2 ? 1 : 0;
  text(n1+" "+held1, 0, 15);
  text(n2+" "+held2, 0, 30);
}

void keyPressed() {
  if (key=='1') { 
    held1=true;
  }
  if (key=='2') {
    held2=true;
  }
}
void keyReleased() {
  if (key=='1') { 
    held1=false;
  }
  if (key=='2') { 
    held2=false;
  }
}

glv · July 13, 2019, 2:08pm

Hello,

Sharing an initial exploration into what your code is doing.
I used “keyCode” in place of “key”.
You can see the “keyCode” in the console; “Shift 1” is “keyCode” 3 etc.
Using the console is a good tool for debugging.

Your sketch did not present any problems here unless I hit the “Shift” key and numbers 1 and 2 on numeric keypad rapidly on and off :

int n1, n2;
boolean held1, held2;
int kP, kR;

public void settings()
  {  
  size(200, 200, P3D); 
  }

public void setup()
  { 
  }

public void draw() 
  {
  background(0);
    
  text(n1 +" " + held1, 0, 15);
  text(n2 +" " + held2, 0, 30);
  }

public void keyPressed() 
  {
  kP = keyCode;  
  println ("kP", kP);

  if (keyCode == 16 || keyCode == 3 || keyCode == 40 ) return;   
  if (keyCode == 49 || keyCode == 129) // '1' pressed
    { 
    n1++; 
    held1=true;
    }
  
  if (keyCode == 50 || keyCode == 130)  // '2' pressed
    { 
    n2++; 
    held2 = true;
    }
  
  if (key == 'b')
    {
    n1 = 0;
    n2 = 0;
    }

  }
public void keyReleased()
  {
  kR = keyCode;  
  println ("kR", kR);   println ();

  if (keyCode == 16 || keyCode == 3 || keyCode == 40) return; 

  if (keyCode == 49 || keyCode == 129)  // '1' released
    { 
    n1--; 
    held1 = false;
    }
  
  if (keyCode == 50 || keyCode == 130)  // '2' released
    { 
    n2--; 
    held2 = false;
    }
  }

Architector_4 · July 13, 2019, 5:34pm

Actually I’ve meant that in an ideal world, code inside of keyPressed would be run every single time a key is pressed down, regardless of what other keys are held or not in the meanwhile.
In all of my code, when needed, I obviously use booleans. The problem still exists though, as sometimes the keyPressed() event is not triggered, so n1 stays as 0 and held1 stays as false even if I’ve pressed and am holding 1, which means that I can’t observe either the boolean or the integer to reliably get the current state of the key.
In my example I’ve used integers only to demonstrate my problem.

InferNova · July 13, 2019, 7:41pm

The problem only exists for you I think. I didn’t get it neither did @kll

Architector_4 · July 13, 2019, 8:03pm

Isn’t this because SHIFT+1 is actually ! (exclamation mark), which does not count as 1? If so, I guess that means that you can hold down 1, but then release an unrelated key !, without ever releasing 1 or pressing ! in the first place.
I guess that’s how the counter is going off into negatives in your case, i.e. not the same thing

Architector_4 · July 13, 2019, 8:04pm

Yeah, I figured. I don’t like it though, and I’m sure there’s someone else in the world dealing with the same problem and not knowing that this forum exists or not bothering to ask about it… maybe…

All I want to do right now is get to the core of this problem, find out why I’m experiencing it, and get rid of it, and I’m looking for anyone’s help with this as I don’t think I can dig that deep into Processing source code to get to it.

glv · July 13, 2019, 8:13pm

Shift +1 (keyCode = 3 for 1 on numeric keypad) is the only thing that gave hiccups but ONLY if I was hitting keys rapidly on and off while testing.

There may be other combinations that created hiccups but I only tested common key combinations to see responses.

Otherwise everything was working.

Try another keyboard and see what happens.

Architector_4 · July 13, 2019, 8:19pm

It’s at software level - I’ve tried it on the built-in laptop keyboard and 2 USB keyboards, and the problem still existed there, only on P2D/P3D Processing sketches, and absolutely nowhere else.
Would be weird if a keyboard knew what software I was using it in and would have a sentient mind of their own, deciding to not send key press events on that specific kind of software just to mess with me!

InferNova · July 13, 2019, 8:54pm

Do you have different oses ? So u could see if it happens on the other os ? Maybe hardware problem.

Architector_4 · July 13, 2019, 9:23pm

As far as I remember, on this exact laptop, back when it had Windows 10, there were no such problems.

I think I should try getting different versions of Processing 3, and see if any one of them would have a better behavior - what if?
I can’t do that right now, but I’ll try tomorrow.

kll · July 14, 2019, 1:29am

so you install win 7 over win 10 on that laptop?
might have lost a needed keyboard driver?

i am not good with that stuff, but my point is that we have some reports about
how many keys ( pressed at the same time ) can be detected ( by processing )
and it was always the keyboard what caused problems.

Architector_4 · July 14, 2019, 3:38pm

No, I’ve nuked Windows 10 and installed Arch Linux ontop, which I’ve noted to be my OS in the first post.
Drivers and the keyboard must be allright, considering that out of many applications, including those using SDL, OpenGL, basic drawing on the window, GTK/QT frameworks, Steam, WebGL browser games, Processing JAVA2D, internal Linux TTY console(outside of anything that renders windows) and more, only Processing P2D/P3D sketches act this way.

InferNova · July 14, 2019, 5:03pm

Are you using latest version of processing ?

Architector_4 · July 15, 2019, 12:44am

The build date on the package is 22nd March 2019, while the timestamp on the Processing downloads page is 3rd February 2019, so it must be the latest version.

InferNova · July 15, 2019, 2:08am

I am preety sure it a os / driver problem.
Best bet is to get a different os and try to see if the issue persists. I have the same version and no problem occurs for me.

Architector_4 · July 15, 2019, 2:24am

I’m uncovering more right now - the problem seems to be related to key repeat delay/rate i.e. the function of the OS where holding a key for long enough it starts repeating the keyPressed() event.

If I disable key repeating (with terminal command xset r off) the problem goes away instantly and I can’t reproduce the issue.

However, if I set repeat delay to 0 (i.e. so that it starts repeating the key instantly as soon as I start holding it, making it impossible to type) and repeat rate to 255 (maximum possible, 255 characters per second) (both with command xset r rate 0 255), the keyPressed() event of the second key misses almost always.

From that I guess that it misses keyPressed() event of a key only if another key is pressed at the same time due to being repeat-pressed by the OS.

I guess this can be explained by P2D/P3D dropping repeated keyPressed() events too sparingly, and by dropping such event at the same time another key is pressed, it drops the keyPressed() event for that key instead, and results in missing it. That is reinforced with JAVA2D renderer not dropping repeated keyPressed() events and not having this issue.

I believe that this is a bug in Processing’s P2D/P3D engine’s key processing code, specifically the one responsible for dropping repeated key events.

I guess I’m the one who points it out after so much time is because my preferred key repeat delay/rate are a bit too extreme compared to normal user’s (xset r rate 170 60, i.e. 170ms delay and 60 presses per second - coincides with P2D’s 60 frames per second therefore I’m having the issue?)

I think I’m ready to go write a smart sounding GitHub issue for it to be fixed now, but I’ll wait for anyone to come maybe say something smart beforehand.

Edit: no one said anything smart in 23 days, so I’ve posted an issue about this on GitHub: https://github.com/processing/processing/issues/5904

InferNova · August 7, 2019, 3:15pm

Hello Again!

Did you attempt on different systems ? I have. And the issue doesn’t exist. Maybe I will try set my keyrepest and see if I get the issue too!

Architector_4 · August 7, 2019, 4:09pm

Sorry, I don’t have any other systems to try this on.

Although, In my previous experience with Windows, its maximum key repeat rate was too small for me, from which I guess it’ll also be too small to frequently experience this issue.

Make sure to hold first key long enough for key repeating to actually kick in though!

Topic		Replies	Views
KeyPressed() for multiple keys pressed at the same time Processing	7	6288	March 24, 2020
Key value disappears after holding two keys Coding Questions	1	443	July 4, 2018
keyPressed is True even with no keys actively pressed after certain inputs in P2D Processing	1	102	September 11, 2023
Lost keyPressed events Processing	3	510	July 29, 2020
Key and keyCode flicker on release Coding Questions	1	408	September 13, 2019

keyPressed() events get missed when another key is held

Related Topics