| Summary: | X11: Wrong initial size in tiling WM (+ solution?) | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Tony Lainson <t.lainson> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED WONTFIX | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 1.2.14 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Attachments: |
patch for X11_Wait(Un)Mapped
Same patch, but for SDL2 |
||
I'm hesitant to change X11 behavior in SDL 1.2. Thanks for the patch though! Created attachment 883 [details]
Same patch, but for SDL2
Made against 6335:fbb84f5b985f
|
Created attachment 646 [details] patch for X11_Wait(Un)Mapped SDL 1.2 often fails to observe a resize event if it happens just as the window is being created. No SDL_VIDEORESIZE event is sent to the application. Any extra space remains black. X11_WaitMapped() (in src/video/x11/SDL_x11modes.c) drops resize events that arrive before the window is mapped (StructureNotifyMask selects both MapNotify and ConfigureNotify events). I think that might be a problem if the window manager resizes the window before mapping it. Neither of the WMs I tried actually do that, but I've attached a patch anyway. The real problem is in try_mitshm() (src/video/x11/SDL_x11image.c): XSync is called with the "discard" parameter set to True, which nukes everything in the event queue. Is there a reason for that? Would anything break if we changed it to False? The XSync(blah, True) calls in other files look deliberate. They make me uneasy, but I don't know what (if anything) should be done about them. In any case, I haven't seen the resize bug since I changed True to False in try_mitshm(). I'm not at all familiar with SDL 1.3, but it looks like the only surviving problem is the XSync in the SHM code (which I haven't tried to trigger). Nice work!