Ubuntu desktop forces a video resize at startup for big windows.
This is not a programming issue (yet) but I just wanted someone's opinion on the default behavior of window managers when they encounter windows of large size - particularly windows that are not full screen but nevertheless match the card's maximum size capacity.
If I were to create a window programatically, I would set the window size, call the tool kit's video mode (in this case SDL) and it would create the window without any problem.
If I create a window and make it automatically full screen (i.e. no borders or button, filling up the screen completely), that's no problem either. It's a single video size call that follows the exact procedure as above.
But if I create a non-full screen window (with borders and buttons) that is as large as my desktop, Ubuntu seems to subsequently lock and center that window to the desktop, which in return sends a SDL_VIDEORESIZE message to the program. This causes many subsequent issues that need to be addressed (especially in an SDL/OpenGL context).
Any insight on this behavior would be helpful.
Note: As far as I know, I'm not using compiz, just the default Ubuntu install.
If you grok 'man xorg.conf' you will see a 'Virtual' setting
Virtual xdim ydim, e.g.
Virtual 1920 1080.
The screen won't go bigger than that. AFAIK you need to patch X code to do that. If you do, and it doesn't readjust it (not sure here) you will have some of the screen offscreen at any point. But X makes up it's mind if it's going to do that or not.
Setting Virtual 2560 1440 ought to allow you to open windows of up to that size. Then as your mouse hits the left edge of screen, and you keep moving it left, the screen will move over to the left border.
Thanks for the reply.
You have some interesting pointers here as for where to look if I want to expect / troubleshoot a maximum screen resolution for my application or if I must be aware of any bigger "virtual" desktop underlying it.
But I wasn't looking for a way to make a bigger window than my actual screen. I simply(!?) pointed the fact that when I create a window as large my desktop, says 1920 x 1080, the window manager (X or maybe some Ubuntu contraption) forces a re-size of that window - even though it ends up being the original size - and therefore causes SDL to send SDL_VIDEORESIZE messages.
For smaller, bordered windows or even a full 1920x1080 "Fullscreen" OpenGL window on start-up (direct to hardware, no buttons or border, the kind of "fullscreen" you get when starting a game, for example), this doesn't seem to affect resizing at all as SDL doesn't send such message.
The impact of this is essentially for debugging: I want my application to run "really fullscreen" in production mode but that is not practical when debugging as I need to switch windows between the app and the debugger (I'm looking at possibilities for remote debugging to help me on this...). But SDL/OpenGL applications are more or less allergic to such resizing, and depending on the platform, one might need to reload all the textures when such resizing occurs.
Essentially, whatever drives my desktop doesn't like big, bordered and buttoned windows and forces it, stretches it, snaps it to the sides, until it's satisfied. In the mean time, I get about 6 SDL_VIDEORESIZE calls made in my program before I can even start my game loop. If I do any texture loading during that process, issues are starting to pop up. I'm in the continuous process of shielding unexpected behaviors in my code from such reloads like pushing back the game loop until I can detect for sure that the window manager has settled for good. But 6 (six) calls! That's a lot of pussyfooting to snap a window.
So, (back to the original question :-) ) is it normal behavior for X, for any Linux desktop with a modern window manager or is it just an Ubuntu thing ?
In all cases, being aware of such issues and shielding my code against any window manager remains the best practice, I guess ... Still it took me a while ... and a few memory leaks to find this out.
Cheers. And a happy new year.
|All times are GMT -5. The time now is 10:55 AM.|