New feature: Hidden RenderWindows

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.

New feature: Hidden RenderWindows

Postby CABAListic » Sun Aug 01, 2010 6:34 pm

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.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 2902
Kudos: 58
Joined: 18 Jan 2007

Re: New feature: Hidden RenderWindows

Postby jacmoe » Sun Aug 01, 2010 6:37 pm

That's some good news! :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, Fueled by Passion.
Ogre AppWizards - Ogre project wizards for VC 8-10, Code::Blocks and KDevelop.
OgreAssimpConverter - command-line to convert models to Ogre format.
TwOgreGUI - wrapper for AntTweakBar GUI library.
I accept donations | Me on Google+
User avatar
jacmoe
OGRE Moderator
OGRE Moderator
 
Posts: 21024
Kudos: 161
Joined: 22 Jan 2004
Location: Denmark

Re: New feature: Hidden RenderWindows

Postby Praetor » Mon Aug 02, 2010 4:26 am

Yes that is pretty handy. Managing primary windows will become much easier.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 3335
Kudos: 3
Joined: 21 Jun 2005
Location: Rochester, New York, US

Re: New feature: Hidden RenderWindows

Postby Jabberwocky » Mon Aug 02, 2010 8:45 am

A very welcome addition.
Image
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
 
Posts: 2818
Kudos: 213
Joined: 05 Mar 2007
Location: Canada

Re: New feature: Hidden RenderWindows

Postby sparkprime » Mon Aug 02, 2010 12:20 pm

Does this allow changing things like antialiasing and vsync on the fly?
User avatar
sparkprime
Ogre Magi
 
Posts: 1132
Kudos: 19
Joined: 07 May 2007
Location: Ossining, New York

Re: New feature: Hidden RenderWindows

Postby CABAListic » Mon Aug 02, 2010 12:27 pm

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 :)
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 2902
Kudos: 58
Joined: 18 Jan 2007

Re: New feature: Hidden RenderWindows

Postby sparkprime » Mon Aug 02, 2010 7:40 pm

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
User avatar
sparkprime
Ogre Magi
 
Posts: 1132
Kudos: 19
Joined: 07 May 2007
Location: Ossining, New York

Re: New feature: Hidden RenderWindows

Postby sparkprime » Mon Aug 02, 2010 7:42 pm

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.
User avatar
sparkprime
Ogre Magi
 
Posts: 1132
Kudos: 19
Joined: 07 May 2007
Location: Ossining, New York

Re: New feature: Hidden RenderWindows

Postby sparkprime » Fri Aug 06, 2010 4:00 pm

What is the difference between setVisible(false) and setHidden(true) then?
User avatar
sparkprime
Ogre Magi
 
Posts: 1132
Kudos: 19
Joined: 07 May 2007
Location: Ossining, New York

Re: New feature: Hidden RenderWindows

Postby sparkprime » Fri Aug 06, 2010 4:19 pm

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.
User avatar
sparkprime
Ogre Magi
 
Posts: 1132
Kudos: 19
Joined: 07 May 2007
Location: Ossining, New York

Re: New feature: Hidden RenderWindows

Postby CABAListic » Fri Aug 06, 2010 4:47 pm

Have you set the aspect ratio of the camera accordingly?
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 2902
Kudos: 58
Joined: 18 Jan 2007

Re: New feature: Hidden RenderWindows

Postby kornerr » Fri Aug 06, 2010 5:16 pm

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.
kornerr
Greenskin
 
Posts: 110
Kudos: 5
Joined: 04 Dec 2005
Location: Russia

Re: New feature: Hidden RenderWindows

Postby CABAListic » Fri Aug 06, 2010 6:17 pm

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.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 2902
Kudos: 58
Joined: 18 Jan 2007

Re: New feature: Hidden RenderWindows

Postby kornerr » Fri Aug 06, 2010 6:32 pm

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 ++.
kornerr
Greenskin
 
Posts: 110
Kudos: 5
Joined: 04 Dec 2005
Location: Russia

Re: New feature: Hidden RenderWindows

Postby CABAListic » Fri Aug 06, 2010 6:41 pm

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.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 2902
Kudos: 58
Joined: 18 Jan 2007

Re: New feature: Hidden RenderWindows

Postby sparkprime » Fri Aug 06, 2010 7:32 pm

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.
User avatar
sparkprime
Ogre Magi
 
Posts: 1132
Kudos: 19
Joined: 07 May 2007
Location: Ossining, New York

Re: New feature: Hidden RenderWindows

Postby CABAListic » Fri Aug 06, 2010 7:42 pm

Can you create a basic repo case for me?
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 2902
Kudos: 58
Joined: 18 Jan 2007

Re: New feature: Hidden RenderWindows

Postby kornerr » Fri Aug 06, 2010 7:44 pm

May be the reason is my software is newer? :P
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.
kornerr
Greenskin
 
Posts: 110
Kudos: 5
Joined: 04 Dec 2005
Location: Russia

Re: New feature: Hidden RenderWindows

Postby CABAListic » Fri Aug 06, 2010 7:50 pm

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 :)
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 2902
Kudos: 58
Joined: 18 Jan 2007

Re: New feature: Hidden RenderWindows

Postby sparkprime » Fri Aug 06, 2010 8:24 pm

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.
User avatar
sparkprime
Ogre Magi
 
Posts: 1132
Kudos: 19
Joined: 07 May 2007
Location: Ossining, New York

Re: New feature: Hidden RenderWindows

Postby sparkprime » Fri Aug 06, 2010 8:25 pm

On what window managers have people reported success?
User avatar
sparkprime
Ogre Magi
 
Posts: 1132
Kudos: 19
Joined: 07 May 2007
Location: Ossining, New York

Re: New feature: Hidden RenderWindows

Postby CABAListic » Fri Aug 06, 2010 9:12 pm

Works fine for me in standard Ubuntu. Since I've deactivated Compiz, that would be Metacity as the window manager.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 2902
Kudos: 58
Joined: 18 Jan 2007

Re: New feature: Hidden RenderWindows

Postby sparkprime » Fri Aug 06, 2010 10:30 pm

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.
User avatar
sparkprime
Ogre Magi
 
Posts: 1132
Kudos: 19
Joined: 07 May 2007
Location: Ossining, New York

Re: New feature: Hidden RenderWindows

Postby sparkprime » Fri Aug 06, 2010 10:58 pm

Ah I see, when you call Camera::setAutoAspectRatio(true) it seems to not update the viewport in any way.
User avatar
sparkprime
Ogre Magi
 
Posts: 1132
Kudos: 19
Joined: 07 May 2007
Location: Ossining, New York

Re: New feature: Hidden RenderWindows

Postby sparkprime » Fri Aug 06, 2010 11:08 pm

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.
User avatar
sparkprime
Ogre Magi
 
Posts: 1132
Kudos: 19
Joined: 07 May 2007
Location: Ossining, New York

Next

Return to Developer talk

Who is online

Users browsing this forum: No registered users and 2 guests