GLFW Input Debouncing?

support
1

Hello,

I’m using GLFW’s key callback to control a camera in a simple (OpenGL) 3D world. I’ve registered a callback function via glfwSetKeyCallback that maintains a global array of booleans: an entry is set when a GLFW_PRESS event occurs and is cleared when the GLFW_RELEASE event occurs.

void glfw_key_callback(GLFWwindow *window, int key, int scan, int action, int mod)
{
	...
	if (action == GLFW_PRESS) {
		keyMap[key] = 1;
	} else if (action == GLFW_RELEASE) {
		keyMap[key] = 0;
	}
}

This keymap is then queried in the main loop by the camera handling code to decide how to move the camera:

if (keyMap[GLFW_KEY_UP]) {
	// Then move the camera forward...
}

This all works as expected, modulo one slightly annoying bug: after a key is released, there is a spurious GLFW_PRESS/GLFW_RELEASE event pair, causing a minor stutter in camera’s motion. I’ve read the Input guide and the API docs, but don’t see anything that would explain this behavior.

I’ve included a link to a small program that demonstrates this problem at the bottom of this post. When running it, I would expect to see a single PRESS/RELEASE pair when I push and release the UP key, but instead see two different PRESS/RELEASE combos:

0
PRESS     <--- me pushing GLFW_KEY_UP
1
1
...
1
RELEASE   <--- me releasing GLFW_KEY_UP
0
0
PRESS     <--- spurious press
1
1
1
RELEASE   <--- spurious release

Is this expected behavior for GLFW? Is there a best practice to eliminate this sort of input “bouncing”? In case it’s relevant, I’m running Ubuntu 16.04, with its default Unity shell.

Link to demo program: https://gist.github.com/anonymous/fa27ad8ce5406445c3797544d6f1b7ce

Thanks in advance!
-Nick

2

GLFW already does this for you, per window. See glfwGetKey.[quote=“huntnb, post:1, topic:776”]
This all works as expected, modulo one slightly annoying bug: after a key is released, there is a spurious GLFW_PRESS/GLFW_RELEASE event pair, causing a minor stutter in camera’s motion.
[/quote]

This sounds like bug #747.

3

That does indeed look like the same bug. Thanks, elmindreda! Any future followups will go to linked issue.

-Nick