This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Simple test case (sdl-resize-bug.c, text/plain, 2014-01-10 03:10:52 +0000, 777 bytes)
• X11_PendingConfigureNotify correct condition (X11_PendingConfigureNotify-ignore.patch, text/plain, 2016-06-05 05:46:01 +0000, 761 bytes)

Reported in version: 1.2.15
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2012-02-24 16:20:34 +0000, Daniel Scharrer wrote:

Since libsdl 1.2.15 resizing the window doesn't always produce SDL_VIDEORESIZE events.

Resizing the window only vertically or only horizontally still produces all SDL_VIDEORESIZE events, but resizing both horizontally and vertically at the same time (for example by dragging the lower right corner in most window managers) doesn't result in any SDL_VIDEORESIZE events. Once the window has been resized both vertically and horizontally, horizontal-only and vertical-only resizes also don't produce any more SDL_VIDEORESIZE events.

Maximizing and restoring the window produces resize events, but also breaks after the window was resized both horizontally and vertically at the same time.

This bug is not present in 1.2.14.

On 2012-03-03 13:07:29 +0000, Sven Arvidsson wrote:

I can confirm this bug.

It "only" seems to happen when SDL_SetVideoMode is called after a resize. If I comment out that call I seem to have no problem getting the events when resizing from a corner.

I will take a shot at bisecting this bug, but since I have zero experience with mercurial I might not be successful.

On 2012-03-03 14:27:14 +0000, Sven Arvidsson wrote:

Mercurial was pretty nice to work with.

The "I just don't know what went wrong" commit is:

changeset: 5620:ad4ed9f0336f
branch: SDL-1.2
user: Ryan C. Gordon icculus@icculus.org
date: Sun Aug 21 11:27:37 2011 -0400
summary: Ignore old ConfigureNotify events during X11 window resize.

Reverting this change fixes the bug here, but it would probably be good if someone else could confirm.

On 2012-03-04 11:11:51 +0000, Daniel Scharrer wrote:

I can confirm that hg backout 5620:ad4ed9f0336f fixes this bug.

I am also calling SDL_SetVideoMode after every resize to adjust the opengl front/backbuffer sizes.

On 2012-04-10 15:26:48 +0000, wrote:

For reference:

We applied this fix at Debian (reverting the commit http://hg.libsdl.org/SDL/rev/ad4ed9f0336f ) due to this bug report:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665779

I will keep an eye on this and will let you know if we run into problems because of the reverted code. Otherwise you can assume that it's working fine for Debian users -- so it will be another confirmation to weight-in in the decision to revert it upstream as well.

On 2012-11-14 08:00:49 +0000, Daniel Scharrer wrote:

The offending commit has since been patched out in the Gentoo [1] and Arch Linux [2] packages.

It would be better if this could be fixed (or even just acknowledged) upstream though.

[1] https://bugs.gentoo.org/show_bug.cgi?id=411539
[2] https://bugs.archlinux.org/task/30650

On 2013-06-13 04:08:33 +0000, Peter Wu wrote:

*** Bug 1539 has been marked as a duplicate of this bug. ***

On 2014-01-10 03:10:52 +0000, Jacob Welsh wrote:

Created attachment 1517
Simple test case

I've found that this is more easily triggered, the longer the time between checking for events, e.g. when framerate is low. Basically, when resize events are coming in from the window manager faster than the app can keep up. I can get resize events to start working again by resizing the window to exactly the size where it got stuck (shown by the white rectangle, in this code), then resizing very slowly. This makes sense based on the logic of the change in original bug (# 1049) -- it is waiting for a resize event of the original size, for reasons I can't quite follow.

On 2015-08-25 09:38:23 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email (icculus@icculus.org) and we'll try to find some way to help you out of your situation.

Thank you,
--ryan.

On 2015-08-29 22:13:41 +0000, Jacob Welsh wrote:

This is definitely still a problem, and the fix has been identified, which is to revert the faulty patch from # 1049.

That patch broke user-resizable windows on X11, in the name of fixing an obscure and unreproduceable bug in program-initiated resizes. In fact, it didn't even fix that as advertised, due to mistaking && for ||, which is why this bug doesn't show up when resizing one dimension at a time.

I can see a possibly more correct fix for # 1049, but I'm not sure of the implications, so unless someone with deep SDL knowledge will be willing to review it, I don't think it's worth the risk.

It's unfortunate that you don't intend to issue any further 1.2 release with such a major bug present in the last one. Hopefully at least accepting the fix in mercurial will reassure Linux distributors that 1.2 isn't dead and they're not stuck maintaining it unilaterally.

As an end-user, "move your program to SDL 2" is not any kind of option, especially considering the many classic games built on 1.2 no longer under development.

As a developer, there are still obstacles to moving to 2. Chiefly, the lack of any formal documentation (the excellent docs of 1.2 were a major strength; a half-finished wiki is not the same thing, needs to be in version control), and the smaller selection of third-party language bindings. That said, 2 does have nice improvements and I appreciate the work that's gone into it.

On 2015-08-30 17:58:05 +0000, Alex Szpakowski wrote:

(In reply to Jacob Welsh from comment # 9)

As an end-user, "move your program to SDL 2" is not any kind of option,
especially considering the many classic games built on 1.2 no longer under
development.

I believe there are plans to have a SDL1.2-on-2 layer to allow programs built against SDL1.2 to actually use SDL2 through a dynamic library shim – but I don't know the development status of it.

(In reply to Jacob Welsh from comment # 9)

As a developer, there are still obstacles to moving to 2. Chiefly, the lack
of any formal documentation (the excellent docs of 1.2 were a major
strength; a half-finished wiki is not the same thing, needs to be in version
control)

The wiki documentation is missing a couple things, but for the most part it's more than adequate. The SDL2 header files also have good in-line documentation.

On 2016-06-05 05:46:01 +0000, Norihiro Kamae wrote:

Created attachment 2480
X11_PendingConfigureNotify correct condition

Condition to be ignored should be both width and height are same to the pending size. If not, ie., width or height is different, the resize event should be processed.

On 2018-07-31 11:21:47 +0000, Ozkan Sezer wrote:

(In reply to Norihiro Kamae from comment # 11)

Created attachment 2480 [details]
X11_PendingConfigureNotify correct condition

Condition to be ignored should be both width and height are same to the
pending size. If not, ie., width or height is different, the resize event
should be processed.

This patch seems to fix the test-case from comment # 7.
Ryan, Sam: should we apply?

On 2018-08-02 07:48:41 +0000, Ozkan Sezer wrote:

Patch from Norihiro Kamae (comment # 11) is now in:
https://hg.libsdl.org/SDL/rev/20cbaf8965fb

Closing this as fixed. If the issue persists, please
reopen this bug.