New feature: Hidden RenderWindows

[CABAListic]

Just a quick note before it gets lost in the Mercurial commit logs: Based on a patch submitted by kornerr I've implemented a new function for RenderWindows, RenderWindow::setHidden(bool). This function can be used to make a given RenderWindow completely invisible; it will vanish from the screen and the taskbar. There's also an accompanying extra param called "hidden" for when you create a new window.

Best use for this is the dummy RenderWindow trick: Create a 1x1 dummy window as your primary RenderWindow and hide it. The window's sole purpose is to carry all the resource handles etc. so that you can destroy and recreate all your actual RenderWindows without having to reload all the resources.

[jacmoe]

That's some good news!

[Praetor]

Yes that is pretty handy. Managing primary windows will become much easier.

[Jabberwocky]

A very welcome addition.

[sparkprime]

Does this allow changing things like antialiasing and vsync on the fly?

[CABAListic]

It should.
Just create a dummy renderwindow as the primary renderwindow and hide it. Then create your *actual* renderwindow. Whenever you want to change settings like vsync and antialiasing, you can destroy and recreate that window with the appropriate values. That is, of course, assuming that the underlying rendersystem can change those values per window. Which I think it should, otherwise those options would be misplaced in the RenderWindow

[sparkprime]

The vsync situation is a bit complicated I think. Still haven't figured it out. RenderTarget::swapBuffers has a param which is ignored on every RenderWindow implementation I checked. It may be the API is a bit silly and needs to be updated.

It seems the Ogre::RenderSystem::_createRenderWindow is the right place to specify vsync

[sparkprime]

There is also RenderSystem::get/setWaitForVerticalBlank

and the RenderSystem::setConfigOption, i.e. the stuff from ogre.cfg or whatever you call it.

edit: It seems these are both for maintaining mVSync in that class. mVSync only purpose is to control the auto window.

So the right thing to do is probably to ignore the stuff in RenderWindow, ignore the ogre.cfg option and the setConfigOption thing. Leave it all to defaults. Make the primary window invisible and specify vsync when creating your custom window.

That is true for D3D9 in windows at least, dunno about GL or Linux.

[sparkprime]

What is the difference between setVisible(false) and setHidden(true) then?

[sparkprime]

I have a problem with aspect ratio when using a custom created window instead of the automatically generated window. What I do is let OGRE create the automatic window with some boring settings, no fullscreen, etc. Then I immediately setHidden(true) on it and Ogre::WindowEventUtilities::messagePump().

Then, I grab the render system and call _createRenderWindow as follows

Code: Select all

                Ogre::NameValuePairList params;
                params["FSAA"] = "0";
                params["FSAAHint"] = "";
                params["vsyncInterval"] = "";
                params["vsync"] = use_vsync?"true":"false";
                params["gamma"] = use_hwgamma?"true":"false";
                params["useNVPerfHUD"] = "true";
                Ogre::RenderWindow *win = rs->_createRenderWindow("Grit Game Window", 800, 600, use_fullscreen, &params);

I store the win pointer somewhere and in the rest of the code I use that instead of root->getAutoCreatedWindow().

What I find is that the first window appears and then disappears, and following that the real window appears. Everything is rendering into it fine but the aspect ratio is wrong. If I resize the window it will be fixed for the lifetime of the program, it is just this first display that is wrong.

[CABAListic]

Have you set the aspect ratio of the camera accordingly?

[kornerr]

I've made a tiny patch, because the "hidden" param was not working for me with GLX. Here it is
Also, Root::createRenderWindow documentation does not mention "hidden" param.

[CABAListic]

It works fine for me. From looking at your patch, it looks invalid because far as I can tell you are removing the call to setFullScreen if a fullscreen window is requested. The only potentially relevant difference I can spot is that you are removing the XMapWindow call before the setHidden call. I'll try that, but as I said: GLX works for me.

[kornerr]

No. The XMapWindow and setFullScreen methods are excessive, because they are already in setHidden method.
Also, I tested the patch, FS works fine. Hidden window never shows up. Just as it should be. And there's no duplication. And it makes code smaller by several lines. Only ++.

[CABAListic]

Ah, you are right, setFullScreen is called in setHidden. Not very readable, though. Still, I don't see why it wouldn't work for you now, but only with those changes.

[sparkprime]

I did have to make the hidden window start off non-fullscreen otherwise it would make the screen flash and change res before it was hidden. It still worked, but was just annoying.

The camera is set properly yes, otherwise the aspect ratio would be always broken, rather than just broken for the initial window placement.

I too am using GLX.

Maybe the reason noone else has this bug is that their window managers resize the window at a different time or something like that. I am using ion so the window gets placed into a frame. It does not get the size it asks for. However this works with the auto window so I don't see why it shouldn't work with the manual window.

[CABAListic]

Can you create a basic repo case for me?

[kornerr]

May be the reason is my software is newer?

Code: Select all

X.Org X Server 1.7.7
Release Date: 2010-05-04
X Protocol Version 11, Revision 0

Also, I'm running Compiz-0.8.

[CABAListic]

Sure, but I mean that I don't understand why the current code is not working for you, but your fix is. Not that I'm opposing the fix (though it needs a good comment because of the hidden call to setFullScreen), but I'd like to understand it, first

[sparkprime]

FWIW I tried kornerr's patch and didn't change anything for me. I'll look into it a bit more, try on windows, etc. If I can't come up with something I'll make a repro case. I suspect my problem is nothing to do with this hidden windows change but is to do with using a manually created window.

[sparkprime]

On what window managers have people reported success?

[CABAListic]

Works fine for me in standard Ubuntu. Since I've deactivated Compiz, that would be Metacity as the window manager.

[sparkprime]

Ah of course what will happen there is that the window will end up the same size as what was specified in the createWindow call. That means any bug where the window resize message was misinterpreted would not be caught, as it would be changing the size to the size already known.

[sparkprime]

Ah I see, when you call Camera::setAutoAspectRatio(true) it seems to not update the viewport in any way.

[sparkprime]

I can trigger the same bug by using the automatic window and just pumping window messages immediately afterwards. This causes _updateDimensions to be called before the autoAspectRatio is set and when it is eventually set there is no update from the camera to the viewport. Calling _updateDimensions on the viewport after the camera has had its autoAspectRatio changed fixes the problem, and it is obviously the same as resizing the window, which also fixed it. Not pumping the messages means all of that camera / viewport code runs before the first time the messages are pumped so that works too. Basically this is a race condition.

An alternative is to set autoAspectRatio before attaching the camera to the viewport.