| Summary: | SDL_WindowFlags optimization and introduction of new flags | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Jon Daniel <jopadan> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED WONTFIX | QA Contact: | Sam Lantinga <slouken> |
| Severity: | API change | ||
| Priority: | P2 | CC: | amaranth72, icculus |
| Version: | HG 2.1 | Keywords: | target-2.0.12 |
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | include/SDL_video.h SDL_WindowFlags optimization and introduction of new flags | ||
would SDL_WINDOW_DESKTOP_STRETCH work / be useful when the window has a border and/or isn't set to be the top-most window (above the task bar etc)? Yeah, the stretch thing isn’t a good idea, because it implies all these API promises we don’t want. Also, we probably shouldn’t add flags that are zero, because being bitwise operations, “flags & SDL_WINDOW_WINDOWED” is always false: a surprising outcome. (That SHOWN and HIDDEN are separate flags is confusing in a different way, because you risk landing in a paradox where both flags are set at the same time.) I’m not against changing from hexadecimal to “(1 << 6)” format though. Easier to see intent and harder to miscalculate! :) --ryan. if (flags != SDL_WINDOW_WINDOWED) (In reply to Jon Daniel from comment #3) > if (flags != SDL_WINDOW_WINDOWED) ...which fails if it's also an SDL_WINDOW_OPENGL window. --ryan. (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. 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. 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. (In reply to Ryan C. Gordon from comment #2) > I’m not against changing from hexadecimal to “(1 << 6)” format though. > Easier to see intent and harder to miscalculate! :) I talked myself out of this, too; when debugging, it's harder to convert (1 << 14) to 0x4000 when deciding what flags a window has. It would be easier to maintain, but hostile to external developers. Resolving this bug. --ryan. |
Created attachment 3847 [details] include/SDL_video.h SDL_WindowFlags optimization and introduction of new flags Add the following flag changes to SDL_WindowFlags and implement the FIXME SDL_WINDOW_WINDOWED = (0 << 0), SDL_WINDOW_DESKTOP_STRETCH = (1 << 13), SDL_WINDOW_FULLSCREEN_DESKTOP = (SDL_WINDOW_FULLSCREEN | SDL_WINDOW_DESKTOP_STRETCH), SDL_WINDOW_FULLSCREEN_DEFAULT = SDL_WINDOW_FULLSCREEN