This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Source code showing error (main.cpp, text/plain, 2019-07-19 17:20:02 +0000, 1533 bytes)

Reported in version: 2.0.8
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2019-07-19 17:20:02 +0000, briggs_w wrote:

Created attachment 3887
Source code showing error

After SDL_SetWindowSize plus SDL_PollEvent, a call to SDL_GetWindowSize returns the old dimensions, not the ones given to SDL_SetWindowSize. (But the window is resized.) Also, things drawn are drawn too far down the screen, offset from the correct position by some amount.

This has not been a problem in MinGW or Visual Studio.

Originally I had sdl2's version as 2.0.8+dfsg1-4ubuntu; OS was 64-bit Ubuntu 4.18.0 on Oracle VM VirtualBox Manager using GNOME Shell and X11. I have since upgraded to Ubuntu 5.0.0 with SDL version 2.0.9+dfsg1-1ubuntu1, showing no change in this behavior.

Putting this code right before the SDL_SetWindowSize call makes SDL_GetWindowSize get the right dimensions:

SDL_Event e; while(SDL_PollEvent(&e));

...but things show up offset in up or down, from their correct positions.

I was able to get the drawing to be in the right place by call to SDL_RenderPresent followed by a delay.

On 2019-07-25 01:49:26 +0000, briggs_w wrote:

Sorry: that was kernel 4.18.0 changed to kernel 5.0.0. Ubuntu was 18.10(cosmic) and now 19.04 (disco).

On 2019-07-30 17:49:36 +0000, Ryan C. Gordon wrote:

(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.

On 2019-09-20 20:47:35 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

On 2019-09-20 20:48:42 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

On 2020-01-30 01:49:38 +0000, Ryan C. Gordon wrote:

So this is happening because we call XResizeWindow() with the new size, but the window doesn't actually transition to the new size until we get a ConfigureNotify event from the X Server (and this might have to make a round-trip through the window manager first, and then it might also be waiting on animation of a window appearing on the screen at whatever level that happens at).

We report the window size that the X server believes during SDL_GetWindowSize(), which doesn't match what we just set it to. The reason adding SDL_PollEvent() calls in fixes it is because it stalls the app a tiny bit and causes a roundtrip to the X server, which usually gives it enough time to get to the right state, but there's no reason this couldn't block for a long time at the mercy of the process scheduler.

We could solve this a few ways, and I'm not a fan of any of these, but:

1. We can block in SDL_SetWindowSize() until we get a ConfigureNotify event, but it's not clear to me X11 will always send one. Can the window manager outright veto an XResizeWindow command, or anything like that?

2. We could keep a field that notes when we set the window size, and if it's > 0, we report the app-requested user size if the time is less than X milliseconds. When a ConfigureNotify event arrives, we set this back to zero and update the window state, since we know the server either accepted the resize or rejected it in some way. If we never get a ConfigureNotify, we set this field back to zero after X milliseconds and generate a fake SDL window size event during PumpEvents, saying the window has been resized by the system back to its old size.

3. We tell people that this might be asynchronous on some platforms, so don't make decisions based on a window size you just set (and if you do, you know what you just set it to, so don't ask SDL for the size), or write code that can deal with whatever the window size is at the time instead of checking it once, etc.

I can just see a million possible failure scenarios where we never get a ConfigureNotify, or someone has a tiled window manager and it forces the window size so you get neither the original size nor the new one, etc.

Lazy me is leaning towards option three, because this is maybe a little bit of a corner case anyhow...? Option # 1 is by far the best for our use case, if we can guarantee we won't hang up in there forever waiting on an event that isn't coming. Option # 2 is just disaster mitigation, but it's going to be nasty.

--ryan.

On 2020-02-14 18:29:47 +0000, Ryan C. Gordon wrote:

Bug # 4646 is basically the same problem (except with window position instead of size), and I went with something like option # 1, except instead of waiting for an event, we query the window's attributes for changes for up to 100 milliseconds. The same solution here is probably the correct thing to do. Check the notes on Bug # 4646 and https://hg.libsdl.org/SDL/rev/f22dd67ec07b for more explanation.

I'll do the same thing for this bug shortly.

--ryan.

On 2020-02-17 21:12:13 +0000, Ryan C. Gordon wrote:

This is fixed in https://hg.libsdl.org/SDL/rev/dbcccb065928, thanks!

--ryan.