[rcore] `GetWindowPosition()` possibly incorrect after virtual screen space rearrangement

[rossberg]

When a user rearranges their monitors in the virtual screen space, or a monitor is disconnected, that may implicitly change window positions, despite the windows remaining stationary. This is not reflected by Raylib's GetWindowPosition function, which uses its own position buffering that doesn't get updated.

With the GLFW backend, it may be possible to set glfwSetMonitorCallback to get notified by such changes.

[raysan5]

@rossberg Do you know if it's possible to track that information with the other backends?

[rossberg]

@raysan5, sorry, I don't. That was just a shot in the dark, I don't even know if that would be the right fix.

To be more precise, the window position actually does get updated eventually, but too late. As a consequence, there is a temporary inconsistency between e.g. GetWindowPosition() and GetCurrentMonitor(). Here is a small repro case:

int x = 0;
int y = 0;
int m = 0;

void report(const char *s) {
  Vector2 v = GetWindowPosition();
  int xx = v.x;
  int yy = v.y;
  int mm = GetCurrentMonitor();
  if (xx != x || yy != y || mm != m) {
    printf("[%s] x=%d y=%d mon=%d\n%!", s, xx, yy, m);
    x = xx; y = yy; m = mm;
  }
}

int main() {
  InitWindow(400, 400, "TEST");
  while (! WindowShouldClose()) {
    BeginDrawing();
    report("after begin");
    EndDrawing();
    report("after end");
    usleep(10000);  // emulate work load
  }
  return 0;
}

On a machine with two monitors,

1. start the program on the primary monitor, then
2. switch the primary monitor to be the other one.

This is what I observe (on Windows 11, initial primary monitor 0 is 2560x1440, monitor 1 is 1920x1080 to its right):

[after begin] x=1080 y=496 mon=0
[after begin] x=1080 y=496 mon=1
[after end] x=-1480 y=496 mon=0

Startup produces the first line. Switching the primary monitor then reorganises virtual coordinates. For one frame, Raylib sees the new screen layout but not the new window position, therefore temporarily reporting that the window got moved to another monitor (which in my actual app then triggers a reconfigure due to a falsely detected resolution change).

I assume the cause is that the change to the screen coordinates is picked up immediately, but the window coordinates only when the event queue is pumped next time.