OgreRenderer resizing issue

[rockoz]

Both CEGUI svn trunk 2577 and 0.7.1 with Ogre1.7.1 or 1.7.0 only use D3D9 rendering sys (openGL is fine, and also the CEGUId3d9/opengl renderer) have this problem.

When sizing demo7 (the same with other demos, demo6, demo8, font demo) app window to fullscreen you will see any of the window's transparent part become like this:


In fact, after some test I find these 'mess' (I dont know which word to use) will show if the windows have alpha channel part after resizing.
like this:



The window will back to normal if you have mouse move in them or drag them to move.
But it's unacceptable because resizing the application window is a usual operation.
Anyone meet the same issue?
Can we solve it?

[CrazyEddie]

I'll have to test it on Windows and get back to you. seems kind of related to this: viewtopic.php?f=10&t=4978

CE

[rockoz]

Thank you CE~

I've read that thread and I cant see the pictures based on my network
So I cant tell whether we are talking about the same issue. And he said samples go well, but they do not in my situation...

Nonetheless, I tried to disable the AutoRenderingSurface property, and the issue is gone.
Hope this info will help

[CrazyEddie]

The image in the other thread is WindowsLook, but basically it's similar to your first image with the white around the transparent parts of the window frame. The info as regards to AutoRenderingSurface is useful, because it basically confirms that it appears to be an issue with clearing the render texture targets before rendering to them after certain events. Hopefully a fix will occur this weekend

CE.

[rockoz]

I just tested the demo again, and I confirmed that with CEGUID3D9renderer, this problem also occured...

By quickly switching between full size and original size of the app window. The CEGUIOpenGLRenderer works fine.

[CrazyEddie]

I've done some testing on this with Ogre and the D3D9 render system, but so far have not been able to reproduce the results. I came to ask which video harware (and driver) you're using, since it appears that it may be a factor. I will also run the tests on alternative hardware, so hopefully a pattern will start to emerge

CE.

[rockoz]

I've tested on both ATI Radeon HD 4800 and GeForce GT 240 and can reproduce this issue.

And the OS is windowsXP sp3. HTH

[CrazyEddie]

Thanks for the info. Unfortunately I tested on ATI RAdeon 4600 and GTX275 but could not reproduce the issue. This was on Windows 7. I also tested this morning with XP SP3 running on a VM, and it was fine there also. In all cases I was using the v0-7 branch of CEGUI and the 1.7.1 Ogre SDK, and I built with vc9.

Obviously this is a very real issue for yourself and some other guys here, though I'm at a loss as to what else I can do to try and reproduce this. Any help is appreciated!

CE

[rockoz]

Thank you CE.

I had some test on Window7. I also test the Sample_Demo7 using transparent part and Ogre1.7.1 build with default settings + D3D9 render system on both XP SP3 and Windows7.
It's really weird that it works fine with the latter.

So I want to know what OS your VM is running on? Is it Windows7, or this situation only occurs on WindowsXP SP3?

[CrazyEddie]

Thanks for the info. It's good that you see the same results as me with regards to Windows 7, at least we have identified some common areas where testing could be focussed

The VM that I tested with is VMWare Fusion, hosted on Mac OS X - because it supports accelerated D3D9

Given the information we now have, I will try and get a native install of XP up and running and test it again on there - this will not happen for a while though (a few days, at least).

CE.

[rockoz]

Hmm... I'm back for this thread and find some new info on Windows7.

The UI windows using AutoRenderingSurface as we know on XP SP3 in my situation will have 'artifacts' at transparent part.
And on Windows7 I find that these window will just disappear if you lock your computer, login again and have the focus on the app.
The renderer is Ogre with D3D9.

Now my program is stuck by this problem, AutoRenderingSurface is quite useful for rotation and RenderEffect, as they are wildly used ,
but I cant release it just with the potential of being seen these 'artifacts' or nothing of the UI...

[CrazyEddie]

And again, I will reiterate my position: I can not reproduce these issues, and therefore I, personally, can not fix it. Somebody who has this issue is going to have to do some debugging for me (and the rest of the CEGUI community), because I can't do that for cases where I can't reproduce the issue. Note that I'm not denying the presence of an issue, here. Come on you guys! Don't let me down

CE

[ianstangoe]

Do you call System::invalidateAllCachedRendering() when resizing?

I've seen this kind of garbage rendering after alt-tabbing and calling the above fixed it, just a thought..

HTH.

[rockoz]

Do you call System::invalidateAllCachedRendering() when resizing?

I've seen this kind of garbage rendering after alt-tabbing and calling the above fixed it, just a thought..

HTH.

Thank you ianstangoe.

Actually System::notifyDisplaySizeChanged() does the same work as invalidateAllCachedRendering().

Code: Select all

   
invalidateAllWindows();
MouseCursor::getSingleton().invalidate();


So this step is definitely done when resizing the app window.
But your method really reminds me. Now I trigger this code at the end of the frame after resolution change, seems like temporary solve resizing problem, although you still can see a flash of those 'artifacts' . And the lock & login situation stays the same. Seems like there is some device lost affect the D3D9 rendering, I'll look into that...

Hope some one will prove this issue and dig out the cause of it.