GNOME Bugzilla – Bug 329732
when down is pressed, the current block falls to the bottom
Last modified: 2012-01-31 23:25:11 UTC
Please describe the problem: if the user presses down to move the current falling block one space down, the current block continues to drop as far as it can go. Steps to reproduce: 1. open gnometris 2. new game 3. press down 4. watch block continue to drop Actual results: Expected results: I would expect the block to drop one space Does this happen every time? yes Other information:
First, an apology for taking so long to get to this. I'm not seeing this here, I have the horrible suspicion that this is a long-standing bug in the keyboard code that I have never reproduced and keeps coming back despite tweaks to the keyboard code that should make it all fool-proof. Could you give me a detailed summary of your system: what sort of hardware (especially whether the CPU is 64/32 bit) you're using, which distribution, etc? The other option is that the game is too slow to render and the keyboard repeat is letting keystrokes build-up. In which case the previous question is also relevant. Do you have a CPU load-metre running and is it showing a lot of CPU activity when the blocks drop?
I am experiencing this bug. I have a pair of Pentium II 350 MHz, and I'm using gnome-games version 2.14.1-0ubuntu2. It seems to me that rendering speed is part of the problem. This bug is more pronounced when using the slow theme (joined), when the window is large, or when the screen is full of blocks. When using the fast theme or the window is very small, pressing down only makes the block drop a couple of lines.
Based on your comments, it sounds like a race condition. I am looking at this now. Hopefully a fix can make it in 2.16.
I experience the same bug. When I press <space>, the block is dropped to its location immediately, when pressing <down> it drops faster than regular speed and cannot be moved left or right- dropping cannot be stopped. While I wouldn't mind if dropping could not be stopped, it really bothers me that I cannot "slide" the block to the left/right once it hits the bottom.
Still happening with GNOME 2.16.0, Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/gnome-games/+bug/52471
Created attachment 74719 [details] [review] add gtk_events_pending to timeouthandler The key_release_event handler is being "starved" by the move-blocks-down timer. These timer events are being dispatched one after another, delaying the dispatch of the key release event. Without going into the depths of glibc 2.10.3 to figure out why it is behaving this way, a simple call of gtk_events_pending() in the tetris.cpp timeout handler appears to prevent this problem.
I mean the glib event dispatcher not glibc obviously.
Peter Williams, I have tested your patch, and it didn't solve the problem. I'm still seeing blocks falling to the bottom sometimes...
Thank you for trying the patch. I'd be interested to hear what method you are using to produce this problem: is it a single key-press when the redraw is slow, or are you holding down the key so that the key-repeats send the blocks to the bottom?
The patch doesn't work for me either. No matter whether I just hit & release down as fast as I can or holding down some time and then releasing it - it still goes to the very bottom with no way to move it again. Sometimes it stops falling, but this is in the ratio from about 1:10 or worse.
OK, I guess I should withdraw the patch then. I'm not sure why it is different on our computers, maybe we have a different glib version. (I'm running 2.10.3) I don't believe that my patch is simply affecting the winner of a race condition in the tetris code, because the key-release handler doesn't even get called until the block has fallen all the way (on my computer at least). So a proper solution will probably require digging into the glib internals to figure out why the key event handler is being starved. One suggestion: the render of the joined theme needs to be faster than the timeout specified (currently 10ms, though it could stand to be bumped to 30ms). This is impossible to guarantee across the board because of different CPU speeds etc, but if it is improved then I think most people will see better behavior. Thanks, Peter
*** Bug 532019 has been marked as a duplicate of this bug. ***
I remember that this bug was introduced in Ubuntu 6.06. In Ubuntu 5.10 it worked just fine. My suggestion is that you check the difference between those two versions to see what changed. Maybe it's possible to find the solution in the old code. In GNOME version numbers that is 2.12.1 and 2.14.1. So looking for the difference between those two versions might help you find out what's wrong. (It kinda seemed like you were stuck.)
*** Bug 561634 has been marked as a duplicate of this bug. ***
Fixed on trunk. On 2.26, if the new clutter engine is enabled with --enable-clutter, this behavior will be fixed. This will be the default for 2.27. SVN commit is r8701: Massive rewrite of movement animation and performance improvements This change reduces the number of callbacks we end up handling by a very significant amount. The strategy for movement of pieces that are in the FALLING state is to use a static Behaviours array that can be stopped, adjusted by appending new knots. And the resumed. This has the huge benefit of making it possible accelerate the piece to a very rapid pace making sure that it never takes more than 60ms to reach the final resting place.
This bug is being reassigned to the "quadrapassel" component so we can close the gnometris bugzilla component. Apologies for the mass email!