Ebiten: examples/windowsize: window constantly changes position without input (only on linux)

[corfe83]

I'm testing latest master. Windows behaves as expected (no input, window stays in one place). On linux, the entire window keeps moving up and to the left.

I used git bisect, and found the regression began with this commit: https://github.com/hajimehoshi/ebiten/commit/51f06139a6a4dd5c154bcfea99fe29011194cad3

[hajimehoshi]

Thank you for reporting. How does the window move?

[hajimehoshi]

moving up and to the left.

I guess the window moves toward the corner slowly (1px per frame). Is this correct?

[corfe83]

It appears to change position with each frame rendered, each frame it moves a few pixels up and a few pixels to the left. The size of the window does not change. All of this happens with no input, I touched nothing on the keyboard.

[corfe83]

Just saw your last comment, yes that sounds right.

[hajimehoshi]

Would it be possible to see s by println?

https://github.com/hajimehoshi/ebiten/blob/3043c6cb8e1821b7ed2ca352e78cff8e72c2f3b5/internal/uidriver/glfw/ui_unix.go#L35-L36

As SetWindowPosition is called every tick at examples/windowsize, there are a very slight difference between positions that are set and that are gotten.

[corfe83]

Sure, I will check tomorrow.

[hajimehoshi]

There are two ways to fix:

1. Fix examples/windowsize not to use WindowPosition. This means we leave WindowPosition unreliable.
2. Fix WindowPosition reliable. This means that the same value passed to SetWindowPosition should be returned by WindowPosition. As the float conversion must include some errors, we'd have to keep the position somewhere instead of GLFW. The problem is that the actual window position might differ from the recorded position, so synchronization might sometimes be required.

Let me think. I think I'll go with 2.

[hajimehoshi]

Hmm, 2. is not so trivial. I'll adopt 1. for back-porting to v1.12 and v2.0, and leave 2. as a new task for 2.2.

[hajimehoshi]

I believe this was fixed. Please take a look.