| Summary: | SDL_VIDEORESIZE events not received when resizing window from the corner | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Daniel Scharrer <daniel> |
| Component: | events | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | amaranth72, jwelsh, m.rochester93, manuel.montezelo, norihiro, philipp.wiesemann, sa, sezeroz |
| Version: | 1.2.15 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Attachments: |
Simple test case
X11_PendingConfigureNotify correct condition |
||
|
Description
Daniel Scharrer
2012-02-24 16:20:34 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. 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. 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. 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. 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 *** Bug 1539 has been marked as a duplicate of this bug. *** 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.
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. 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. (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. 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.
(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? 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. |