Unclear how to (reliably) process key/window events

[matthijskooijman]

I've tried using CImgDisplay for showing a small window and processing key events, which is pretty much exactly what I was looking for, nice!

However, I'm a bit confused about how to handle (key) events reliably. What I want to do is simply process all key events in the order that they come in. Looking at key events, I see two relevant methods for this:

• The key(pos) and released_key(pos) method, which returns a key event from the queue, where position 0 is the most recent one. This just returns it, it does not modify the queue itself.
• The setkey() method, which clears the queue.

Say that there are two events in the queue. There's a few problems:

• There size of the queue is not kept, so to access the oldest event, I have to start from pos 0 and go up until I find the first position that has neither a key event or a key released event, then go back one position.
• Once I read the oldest slot, I cannot remove it from the queue until I read all of the queue.
• However, key events are added from a different thread, so new events can appear at any time. This means new keys can be added between reading the first and second key (shifting the positions), causing events to be missed.
• Even more, keys could be added after deciding which event is the oldest and reading it, causing an event to be missed.
• Looking at the implementation, even individual methods are not implemented atomically, so I think that even things like clearing the queue could be interrupted by adding an event or other unexpected things.

Looking at the examples, most of them seem to just look at the most recent key event and after processing it, clear the event queue (potentially missing key events when they occur quickly). For those examples, there seems to be no point in keeping a queue of 128 positions, just one would have done the same.

So I'm wondering: How was all this intended? Am I missing something here?

[dtschump]

Hello Matthijs,

Indeed, we can say that the way CImgDisplay processes key events is 'rudimentary'. That's because I've never really needed to make complicated key detections so far with CImg. TBH, I almost never used the CImgDisplay::keys() and CImgDisplay::released_keys() methods, but rather the individual CImgDisplay::is_keyESC() methods to check if a particular key is pressed or not, which I found more convenient (but if they are not tested quick enough, there is also a chance we miss some key press with those too). All your points are then valid. The key detection system should be probably improved.

[matthijskooijman]

Ok, good to know. For now, I'll just roll with this (it's just a rough tool for internal use only that I'm working on), maybe I'll come back to this if I run into problems.

but rather the individual CImgDisplay::is_keyESC() methods to check if a particular key is pressed or not, which I found more convenient (but if they are not tested quick enough, there is also a chance we miss some key press with those too).

Right, my bigger worry would be that you end up processing a keystroke more than once, though.