CEGUI (Crazy Eddie's GUI) Forums

Basically the problem is when I Alt+Tab away from a fullscreen app and back the menu doesn't re-appear, I'm using the old style CEGUIRQListener approach to rendering the gui, and in my WM_ACTIVATE message I call System->signalRedraw() which use to work fine in the 0.6.x series. I've also tried calling RenderingRoot->invalidate() without success, is there something else I need to do to force the gui to redraw?

This is using the CEGUIOgreRenderer in DirectX 9.

Thanks.

I have no info regarding this at the moment. I'll have to test this specifically and get back to you.

CE.

Ok, thanks for picking up on it.

A little extra info to help...

I rolled back to 0.7.1 stable release and after Alt+Tab back to app the gui has still disappeared, but if I move the mouse over each gui element they get redrawn (this doesn't happen under SVN), however the mouse cursor never reappears

I used the ScrollablePane demo as a test and in DirectX it exhibits this behaviour but OpenGL is fine..

Hope this helps!

Thanks for the info, I'm going to ask for a little bit more...

Is the scrollable pane demo the only demo that exhibits the behaviour?
Is the demo using the 'regular' method for drawing, or did you modify it to use the older approach?
Which hardware do you get the issue on?

So far I have tested this using the unmodified Scrollable pane demo on nVidia hardware but was not able to reproduce the issue I'm about to test on ATI hardware.

CE

Ok. No issues on ATI either.

These tests were done using 0.7.1 release version of CEGUI and Ogre 1.7.0 on Windows 7.

Does the Ogre.log mention any issues as regards to D3D after the alt-tab back?

As a wild shot in the dark, you could try a call to CEGUI::System::notifyDisplaySizeChanged once you've come back to your app.

CE.

Hmm, thats disappointing then

Just tried demo6 and thats the same, I left both demos as is, I'm running XP SP3 on an NVIDIA Geforce 285GTX, I think we have another card in a machine somewhere so I'll try it out on that and report the results.

I tried the notifyDisplaySizeChanged() method also, no effect.

Nothing mentioned in ogre.log either:


[Edit]
Just tested on a Quadro card with same results, I can get the buttons back as soon as the mouse enters the widgets area but I can't get the cursor back, anyway of invalidating the cursor rect?

It seems the "AutoRenderingSurface" flag is having an effect, I have single and twin viewport versions of my application, in the single viewport version I use the default rendering method to render the gui and I don't set the "AutoRenderingSurface" flag on my root window, this results in the buttons reappearing when I move over them. However if I run the twin viewport (Stereo rendering) then I need to set the "AutoRenderingSurface" on my root window and use the old-style CEGUIRQlistener rendering method, this results in a total loss of all gui elements.

Ok. Thanks again for the extra information. While I still don't have a solution right at the moment, I feel we're establishing a good foundation where hopefully I will eventually be able to reproduce this and then either fix it or offer some kind of solution or work around.

The fact that both the demos you tried exhibit the behaviour and were unmodified is great to learn. The fact you have the 285GTX as opposed to my 275GTX is also very good, since they're very much the same hardware. So that leaves drivers, Ogre version(?) and the XP / Win7 parts as the only potential differences.

To answer the question about invalidating the cursor, normally this would never be necessary - so that seems to indicate an issue with textures referenced by the cached geometry. If you're using the regular cursor (and not a fake cursor that's really a Window), the only way I can think to do that is to set a different cursor image, and then reset the original one.

For Window invalidation in general, obviously there's the Window::invalidate function which you've not had much luck with. You may / may not be aware that the svn code (both trunk and the stable v0-7 branch) has an overload of invalidate that takes a boolean that specifies whether to also invalidate all child windows - so calling that with true on the root window is one way to hit all windows simultaneously. So that might be worth a try if you did not already try that.

I'll attempt to look into this some more - perhaps it may have to wait until early next week - but I may get an XP install up and running to see if that does make the difference.

CE.

Hi CE,

I did try this on my home machine also, which is running win 7 on an ATI 4870 and had the same problem. I haven't had time to try updating to the latest version of OGRE yet but thats my next port of call to see if that makes a difference..

Regards, Ian.

Hmm. I guess that rules out the WIndows version difference then. Which Ogre were you using then, 1.6.x? I'll have another play around on windows tomorrow and see if I can break it.

CE.

Yeah, we're stuck on 1.6.2 due to some discrepancies with the way animations are handled with the latest OGRE, even 1.6.5 has issues!

I'm pretty certain all I've done is checkout the latest SVN of cegui, build it against OGRE 1.6.2 and use the default rendering implementation, I'm going to try and test that again tonight at home. But so far it definitely exists on the 3 different configurations I've tested it on.

I know I had exactly the same issue with 1.6.2, where coming back from a device lost would result in the gui disappearing, however rolling over all the elements forced them to be redrawn, and the mouse didn't disappear. I tracked down a solution by forcing the redraw in the renderQueueEnded callback, as we'd setup the gui rendering in a renderQueueStarted callback.

Obviously this is exactly what I'm doing with the latest code but its not having the desired effect, and the CEGUIRQListener code you posted for me by default renders in the renderQueueEnded callback so I don't understand why its not working

Thanks for looking at it though!

Ian.

Just an update, got round to testing with OGRE 1.7.1 + CEGUI SVN (default rendering) + windows 7 and the problem isn't there, so its obviously an issue against OGRE 1.6.2. I'll try the CEGUIRQListener approach tomorrow to check that too, but If you manage to get around to solving it for 1.6.2 that would be great, however looks like an ideal case for us to upgrade our codebase to the latest versions

[edit] Tested the CEGUIRQListener approach and that too seems fine... [/edit]

Cheers, Ian.

Cool. Thanks for confirming this. I'll be testing this with Ogre 1.6.2 later today and hopefully will get a fix in for this issue (unless it breaks things otherwise). I'll advise either way later on today, so watch this space...

CE.

Excellent, much appreciated!

Well, I've managed to reproduce some issues...

In full screen mode I'm getting an Access violation upon tabbing back, I've not really gotten very far with this one yet due to me not really being set up for Windows development / debugging these days

I was, nonetheless, able to reproduce the specific issue you are having, albeit in windowed mode - and I'm looking into that. The issue is basically one of unmanaged textures and vertex buffers not having thier content regenerated after the device reset has occurred. I'm uncertain we can ever fully automate that process since we can't get informed about when these events occur (at least I believe this is true for Ogre 1.6), however a function on the OgreRenderer to trigger all the updates / invalidations is a likely middle-ground solution and is what I intend to provide. This being said, I have to play around some more to get a working version of this!

All fun stuff!

CE.