Can't do a screenshot for this, can only try to describe it. The "hit zone" for buttons is sometimes low, by about 15-20 pixels (don't know if it is also wrong horizontally). When time is running down and you're in panic mode it can lead to undesired actions.
OS: Windows 10. I had the same issue for at least the previous release, maybe last 2.
I haven't been able to determine exact circumstances where/when it occurs. And it is not always like this. I know that doesn't help but I am not expecting it to happen so I can't do a traceback of actions when it does. My shame, as always, is great.
2.1.5 QML - Button "hit zone" is sometimes wrong
Thanks for the report — and no shame needed, this is exactly the kind of thing that's hard to catch. It's plausible, and I have an idea what could cause it, but I need your help to narrow it down.
Some background on why this is odd: in the QML client, the drawing and the click detection of a button use the very same geometry. So if a button were simply laid out in the wrong place, it would be drawn in the wrong place too — the two can't drift apart from a layout mistake. A real offset between "where I see it" and "where I have to click" can basically only come from the window level: the window's rendering scale and the mouse coordinate mapping disagreeing, e.g. after a DPI/scaling change or a window state change.
That would fit your description surprisingly well. With such a mismatch the error is zero at the top of the window and grows towards the bottom — which is precisely where the action buttons sit. So you'd notice it only there, and horizontally it would be off too, but much less (that matches your "don't know if it is also wrong horizontally").
The one test that would settle this — no special build needed:
Next time it happens, move the mouse slowly over the buttons without clicking.
• Does the cursor turn into the "pointing hand" only when it is already 15–20 px below the button?
• Do the small buttons in the row above (1/3, 1/2, Pot, All-In) light up on hover while the cursor visibly sits below them?
If yes, it's a genuine coordinate offset in the window, and I know where to dig.
If no — hover looks correct, only the click goes somewhere else — then it's something entirely different (something invisible swallowing the click, or a timing effect), and I'd look in another place.
By the way, your instinct about "undesired actions" is right and it's the reason I want to fix this: directly above Fold/Check/Raise sits the row with the pot-size buttons and All-In. With the hit zone shifted down, a click aimed slightly high at Fold can land on All-In. Not good.
A few questions that would help:
1. What is your Windows display scaling set to (Settings → System → Display → Scale)? 100 %, 125 %, 150 %?
2. Do you use more than one monitor, and do they have different scaling? Do you ever drag the PokerTH window from one to the other?
3. Do you regularly switch between fullscreen and windowed mode (F11)? If so: does the problem tend to start after such a switch? Same question for maximizing/restoring the window.
4. Once it's wrong — does it stay wrong for the rest of the session, or does it fix itself after a while?
5. Does resizing the window once (drag an edge, or maximize + restore) make it go away?
6. Does it also happen in the lobby (e.g. the buttons there), or really only at the table?
Even a partial answer helps — especially question 3 and the hover test.
Some background on why this is odd: in the QML client, the drawing and the click detection of a button use the very same geometry. So if a button were simply laid out in the wrong place, it would be drawn in the wrong place too — the two can't drift apart from a layout mistake. A real offset between "where I see it" and "where I have to click" can basically only come from the window level: the window's rendering scale and the mouse coordinate mapping disagreeing, e.g. after a DPI/scaling change or a window state change.
That would fit your description surprisingly well. With such a mismatch the error is zero at the top of the window and grows towards the bottom — which is precisely where the action buttons sit. So you'd notice it only there, and horizontally it would be off too, but much less (that matches your "don't know if it is also wrong horizontally").
The one test that would settle this — no special build needed:
Next time it happens, move the mouse slowly over the buttons without clicking.
• Does the cursor turn into the "pointing hand" only when it is already 15–20 px below the button?
• Do the small buttons in the row above (1/3, 1/2, Pot, All-In) light up on hover while the cursor visibly sits below them?
If yes, it's a genuine coordinate offset in the window, and I know where to dig.
If no — hover looks correct, only the click goes somewhere else — then it's something entirely different (something invisible swallowing the click, or a timing effect), and I'd look in another place.
By the way, your instinct about "undesired actions" is right and it's the reason I want to fix this: directly above Fold/Check/Raise sits the row with the pot-size buttons and All-In. With the hit zone shifted down, a click aimed slightly high at Fold can land on All-In. Not good.
A few questions that would help:
1. What is your Windows display scaling set to (Settings → System → Display → Scale)? 100 %, 125 %, 150 %?
2. Do you use more than one monitor, and do they have different scaling? Do you ever drag the PokerTH window from one to the other?
3. Do you regularly switch between fullscreen and windowed mode (F11)? If so: does the problem tend to start after such a switch? Same question for maximizing/restoring the window.
4. Once it's wrong — does it stay wrong for the rest of the session, or does it fix itself after a while?
5. Does resizing the window once (drag an edge, or maximize + restore) make it go away?
6. Does it also happen in the lobby (e.g. the buttons there), or really only at the table?
Even a partial answer helps — especially question 3 and the hover test.
-
JumlyGurm
- Posts: 20
- Joined: Wed Jan 11, 2017 12:00 am
- Location: Zoobzoob Province, Zimbabwe
- Been thanked: 4 times
1 & 2. Single monitor at 1920x1280 and 100% scaling.
3. I stay windowed so I can do other things when not in the hand
4. To be determined.
5. To be determined.
6. To be determined.
It may correspond with changing the game's window size.
Further sleuthing to come.
3. I stay windowed so I can do other things when not in the hand
4. To be determined.
5. To be determined.
6. To be determined.
It may correspond with changing the game's window size.
Further sleuthing to come.
-
JumlyGurm
- Posts: 20
- Joined: Wed Jan 11, 2017 12:00 am
- Location: Zoobzoob Province, Zimbabwe
- Been thanked: 4 times
Okay, I think I was able to replicate the issue. Stretching the game window down causes a zone below equivalent in height to the top row that disappears (where the "leave game" and "settings" buttons appear).
Screenshot attached (redacted parts actually helped shrink file down to adequate size).
Note the pink/fuschia indicators.
The text below the Call button ("checkmate.") is from another window on the screen but below that is where the current window's border is, where the stretch happens.
And it gets fixed when I click on the game window's titlebar and merely drag the window.
Screenshot attached (redacted parts actually helped shrink file down to adequate size).
Note the pink/fuschia indicators.
The text below the Call button ("checkmate.") is from another window on the screen but below that is where the current window's border is, where the stretch happens.
And it gets fixed when I click on the game window's titlebar and merely drag the window.
- Attachments
-
- PokerTH-QML-vertical bug2.png (209.71 KiB) Viewed 56 times
One test could tell exactly where to fix it — no special build needed:
Create a text file in your PokerTH installation folder (the one containing pokerth_qml-client.exe), paste this in, save it as test1.bat:
Then a second one, test2.bat:
(The %~dp0 part is just "the folder this .bat lives in", so it works no matter where you double-click it from. Make sure Windows doesn't save the files as test1.bat.txt — in Notepad, choose "All files" as the file type.)
Start the game through test1.bat, stretch the window down a few times, and see whether the bug still occurs. Then the same with test2.bat. (Only one at a time, please — otherwise I can't tell which one did it.)
Those two switches change how the client draws: the first one changes when frames are rendered, the second one changes what it renders with. Whichever of the two makes the problem go away tells me which layer is at fault — and then I can either ship that setting by default on Windows or force a full repaint after every resize, which is exactly what your "drag the window" trick does by hand.
Create a text file in your PokerTH installation folder (the one containing pokerth_qml-client.exe), paste this in, save it as test1.bat:
Code: Select all
@echo off
set QSG_RENDER_LOOP=basic
start "" "%~dp0pokerth_qml-client.exe"Code: Select all
@echo off
set QSG_RHI_BACKEND=opengl
start "" "%~dp0pokerth_qml-client.exe"Start the game through test1.bat, stretch the window down a few times, and see whether the bug still occurs. Then the same with test2.bat. (Only one at a time, please — otherwise I can't tell which one did it.)
Those two switches change how the client draws: the first one changes when frames are rendered, the second one changes what it renders with. Whichever of the two makes the problem go away tells me which layer is at fault — and then I can either ship that setting by default on Windows or force a full repaint after every resize, which is exactly what your "drag the window" trick does by hand.