KeyReleased Event isn't always triggered (bug)

[Yenaled]

Hello everyone, I'm new to this forum. Anyhow, I recently upgraded to the newest version of SFML 2.0 because I wanted to build SFML from source (I needed to modify the source so that I could implement point looping for music). When I upgraded to this newest version, I soon realized that the keyreleased events did not work 100% of the time. This proved to be quite troublesome for my tile-based game which relied on keyreleased events to stop my sprite from moving.

It seems that I am not the only one who has come across this issue:
http://en.sfml-dev.org/forums/index.php?topic=11482.0
(Look at the 6th post of the thread to see minimal code of this problem)

Coincidentally enough, like the author of the above thread, I am also using Ubuntu 12.04. I have not verified the existence of this bug on other operating systems.

I did some investigating: It appears that the root of this problem lies in processEvent method located in the file: Window/Linux/WindowImplX11.cpp
Furthermore, within the processEvent method, the bug seems to arise in the implementation of detecting repeated events. I did a search, and found that the detecting repeated events algorithm was modified a few months back because of a problem with events firing multiple times: http://en.sfml-dev.org/forums/index.php?topic=10156.0

Seems like when one bug is fixed, another one arises, eh? The fix to prevent KeyPressed and KeyReleased events from firing multiple times seems to have introduced the problem of the KeyReleased event not always being triggered.

When I modified the file to revert back to the older version of the algorithm, and then built the modified version of SFML 2.0, everything is working... well, at least in regards to the triggering of the KeyReleased Event. Hopefully, this bug will be resolved in future releases of SFML.

[FRex]

It's known: https://github.com/SFML/SFML/issues/404

[Yenaled]

Thanks for your reply. I'm surprised I wasn't able to find that post. In any case, disregard this thread. Thanks again.

[FRex]

This is not a forum post, it's issue on github repository for SFML.

[Laurent]

Since I can't reproduce the problem using this code, I'll need some help.

In Linux/WindowImplX11.cpp, line 630, there is a "<= 5". Could you try to replace 5 with 0, and see if the error persists? If it works, try other values (1, 2, 3 and 4). Chances are that the old bug of repeated events come back, it would be great if you could watch this one too when testing the different values.

[Laurent]

Ok, ignore my previous post, I'll try a more aggressive solution: stealing the code from SDL

Since their code is more simple, more compact and obviously works perfectly (and they already got it from another project), let's just use it.

Could you try to replace the ugly hack which detects repeated keys in SFML with this one?

    if (windowEvent.type == KeyRelease)
    {
        // Check if there's a matching KeyPress event in the queue
        XEvent nextEvent;
        if (XPending(m_display))
        {
            // Grab it but don't remove it from the queue, it still needs to be processed :)
            XPeekEvent(m_display, &nextEvent);
            if (nextEvent.type == KeyPress)
            {
                // Check if it is a duplicated event (same timestamp as the KeyRelease event)
                if ((nextEvent.xkey.keycode == windowEvent.xkey.keycode) &&
                    (nextEvent.xkey.time - windowEvent.xkey.time < 2))
                {
                    // If we don't want repeated events, remove the next KeyPress from the queue
                    if (!m_keyRepeat)
                        XNextEvent(m_display, &nextEvent);

                    // This KeyRelease is a repeated event and we don't want it
                    return false;
                }
            }
        }
    }
 

[Yenaled]

All right, I tested it, and it seems to work.  So I'll continue using that version, and if I encounter any problems, I'll post here.

I also tried your previous suggestion: replacing <= 5 with various values in the current version. Replacing 5 with 0 still resulted in the problem of KeyReleased events not always triggering, albeit at a MUCH lower frequency (I spent about 5-10 minutes pressing and releasing keys on my keyboard, and the problem only came up once). I experimented with some other values: It seems that the higher the value, the more likely it is that the KeyReleased event will not trigger when it's supposed to (but, yes, setting it to 0 still doesn't fix the problem).

[Laurent]

Thanks

Thanks for testing, at least now I know why the previous algorithm failed: KeyReleased events were ignored when they were triggered exactly at the same timestamp as a duplicated KeyReleased event.