We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1430 - SDL_VIDEORESIZE events not received when resizing window from the corner
Summary: SDL_VIDEORESIZE events not received when resizing window from the corner
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: 1.2.15
Hardware: x86_64 Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
: 1539 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-02-24 16:20 UTC by Daniel Scharrer
Modified: 2018-08-02 07:48 UTC (History)
8 users (show)

See Also:


Attachments
Simple test case (777 bytes, text/plain)
2014-01-10 03:10 UTC, Jacob Welsh
Details
X11_PendingConfigureNotify correct condition (761 bytes, patch)
2016-06-05 05:46 UTC, Norihiro Kamae
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Scharrer 2012-02-24 16:20:34 UTC
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.
Comment 1 Sven Arvidsson 2012-03-03 13:07:29 UTC
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.
Comment 2 Sven Arvidsson 2012-03-03 14:27:14 UTC
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.
Comment 3 Daniel Scharrer 2012-03-04 11:11:51 UTC
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.
Comment 4 manuel.montezelo 2012-04-10 15:26:48 UTC
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.
Comment 5 Daniel Scharrer 2012-11-14 08:00:49 UTC
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
Comment 6 Peter Wu 2013-06-13 04:08:33 UTC
*** Bug 1539 has been marked as a duplicate of this bug. ***
Comment 7 Jacob Welsh 2014-01-10 03:10:52 UTC
Created attachment 1517 [details]
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.
Comment 8 Ryan C. Gordon 2015-08-25 09:38:23 UTC
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.
Comment 9 Jacob Welsh 2015-08-29 22:13:41 UTC
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.
Comment 10 Alex Szpakowski 2015-08-30 17:58:05 UTC
(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.
Comment 11 Norihiro Kamae 2016-06-05 05:46:01 UTC
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.
Comment 12 Ozkan Sezer 2018-07-31 11:21:47 UTC
(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?
Comment 13 Ozkan Sezer 2018-08-02 07:48:41 UTC
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.