(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.0, Priority 1.

This means we're in the final stretch for an official SDL 2.0.0 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.0 release, and generally be organized about what we're aiming to ship.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.

Taking a look at this.

--ryan.

The default behavior as of WinXP is to clip windows to the size of the desktop (give or take a few pixels). So running one of the test apps with --geometry 3000x3000 will get a window that's the size of the desktop.

One can take heroic (but officially documented) measures to override this, but I'm inclined to say we shouldn't mess with the default behavior here. Should we just disable that test on Windows?

(Where this specifically happens: we call CreateWindow() in SDL_windowswindow.c, which eventually triggers a WM_WINDOWPOSCHANGED event. In there, we ask for the new window's current size and update the SDL_Window struct to match. At this point, Windows has already clipped our window to the desktop.)

Tossing this back to Sam; close this if you want to stick with what's already there.

(Also: It's worth noting that, when centering new windows, since we decide the position of the window by the requested size before our win32 layer creates the window, and before Windows decides to clip it, if you ask for a 10000x10000 window, you won't get that size, but you'll get something that's really offscreen. Probably not worth fixing, though.)

--ryan.

I disagree to close the bug as a NoOp.

The desktop size and the window size should be independent and that's how it works on X for example. If the platform chooses to mess with that, well, that's a poor implementation choice on that platform. From what you describe, Windows seems to mess with that.

Here is what I would suggest we do:
- Fix the Windows behavior by overriding the WM_GETMINMAXINFO message.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632626%28v=vs.85%29.aspx

or

- Ensure that on Windows we do get, has at least the desktop size. This does not seem to work, i.e. in the test below the desktop width was 1920, a set of 1921 was clipped to 1918 (not 1920). So there is an off-by-1 error somewhere in the code on either side.
- Update the documentation indicating that the requested size is not guaranteed and may be clipped.
- Consider updating the API from
   void SDL_SetWindowSize(SDL_Window* window, int w, int h)
to 
   int SDL_SetWindowSize(SDL_Window* window, int w, int h)
and return a (-1) when the requested windows size could NOT be set and was clipped. This is actually the better way to implement this API, since clipping or size limitations are always possible on any platforms, <1 inputs do not make sense, etc.

(In reply to comment #4)
> The desktop size and the window size should be independent and that's how it
> works on X for example. If the platform chooses to mess with that, well,
> that's a poor implementation choice on that platform. From what you
> describe, Windows seems to mess with that.

I'm not sure I disagree with them on this point. I imagine they've fielded many, many questions in the Win95 days about "this window is off my screen entirely, how do I get it back or resize it if I can't reach the title bar with the mouse?"

Like this one.  :)

    http://blogs.msdn.com/b/oldnewthing/archive/2009/05/11/9601136.aspx

> Here is what I would suggest we do:
> - Fix the Windows behavior by overriding the WM_GETMINMAXINFO message.
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms632626%28v=vs.
> 85%29.aspx

Yes, that's the heroic-but-officially-documented measure I mentioned. That event isn't triggering for window creation, but we can probably force a SetWindowPos() call at the appropriate time to fix it once Windows clips the size (that's the heroic part).

Also, there's no way to say "don't limit the window at all" (but you could say the maximum is 999999999 or whatever).

> - Ensure that on Windows we do get, has at least the desktop size. This does
> not seem to work, i.e. in the test below the desktop width was 1920, a set
> of 1921 was clipped to 1918 (not 1920). So there is an off-by-1 error
> somewhere in the code on either side.

I think they steal some pixels for themselves in the code that clips to the desktop; I don't think this is us...I get the 1918 value directly from Windows in this case. Maybe a borderless window would fare differently, I'm not sure.

> - Consider updating the API from
>    void SDL_SetWindowSize(SDL_Window* window, int w, int h)
> to 
>    int SDL_SetWindowSize(SDL_Window* window, int w, int h)
> and return a (-1) when the requested windows size could NOT be set and was
> clipped. This is actually the better way to implement this API, since
> clipping or size limitations are always possible on any platforms, <1 inputs
> do not make sense, etc.

That's an interesting idea, but I don't think we should do it for 2.0.0 (but let's leave this bug open for now so we revisit it afterwards, whatever we end up deciding to do).

--ryan.

Ryan and I fixed it.
http://hg.libsdl.org/SDL/rev/7e053ad01aa3

Reopening - there is still an off-by-one error somewhere.

Running
  ./testautomation --filter video_getSetWindowSize
shows this when trying to set a window size < screen size, i.e. on my 1080p LCD:

...
INFO:  08/08/13 22:10:46: Assert 'Call to SDL_SetWindowSize(...,1919,1079)': Pass
INFO:  08/08/13 22:10:46: Assert 'Call to SDL_GetWindowSize()': Pass
ERROR: 08/08/13 22:10:46: Assert 'Verify returned width; expected: 1919, got: 1918': Failed
ERROR: 08/08/13 22:10:46: Assert 'Verify returned height; expected: 1079, got: 1078': Failed
...

Can you debug into it?  It works for me here, running in a Windows 7 VM:
INFO:  08/11/13 23:49:37: Assert Summary: Total=227 Passed=227 Failed=0
INFO:  08/11/13 23:49:37: Total Test runtime: 0.2 sec
INFO:  08/11/13 23:49:37: >>> Test 'video_getSetWindowSize': Passed

Closing this bug as "no repro".

Test cases 
./testautomation --filter video_getSetWindowSize --iterations 10
passes on VS/Win7 or cygwin/mingw32.