[BUG]Screen Flicker with Irrlicht on Windows Resize

[DtD]

The best way to describe this problem is to show it in action:
http://www.dtdsoft.com/temp/Sample_Firs ... atic_d.exe (Place in your CEGUI/bin directory so it can access the default imagesets and such)
Basically: When a window is resized in CEGUI the other things rendered by Irrlicht flicker black.

To reproduce the bug using the examples:
On line 172 of CEGuiIrrlichtBaseApplication.cpp, chane

Code: Select all

d_driver->beginScene(true, true, irr::video::SColor(0, 0, 0, 0));

to

Code: Select all

d_driver->beginScene(true, true, irr::video::SColor(0, 255, 0, 0));

This causes the background to be red so you can see the flicker. Most of the samples have a background GUI element by default, so they will need it removed. The "FirstWindow" sample has no background so you see it right away.

Using:
MSVC Pro 2009
Irrlicht 1.6 as Static Debug with CEGUI (Compiled by me)
CEGUI Compiled as Static Debug by me using this premake configuration file
Precompiled Dependencies (Static, Debug)

I've been able to reproduce with multiple systems. Still affects it if objects are actually in the scene (I tested with the Maya Camera, a sphere on a fly circle animator, and a skydome.)

Finnally: Here is my CEGUI.log http://pastebin.com/f15226728

Also, I tried telling Irrlicht to not clear the screen, so my cursor and window ghost when I move them, but if I resize a window the whole thing clears and is reset.

EDIT:
I have also noticed this flickering when you type in edit boxes. Also, the background behind the text shows through the anti-aliased areas. But I think this is a Irrlicht bug because I have noticed it before when I use render targets (which I suppose CEGUI is using)
I tried ensuring the viewport and rt were proper before rendering to see if CEGUI was changing them. I also discovered a window with a very short (impossible UDims - it was an accident) height can cause Irrlicht to spam "Failed to set viewport" in DX9 anyway.

~DtD

[CrazyEddie]

Hi,

I think this flickering is a side-effect of the RTT technique employed (in this case it's likely copied, not drawn directly to texture). Basically, CEGUI is called and uses Irrlicht render to texture calls to cache certain imagery. When using copy method for RTT, content is drawn to front buffer first and later copied to textures, but it's this overdrawing of the front buffer that causes the flicker.

In order to mitigate this issue we're going to have to either require that RTT is done directly (which we can't really stipulate, so is a non-starter), or split the rendering process into two phases - one where RTT content is drawn, which would be called prior to any other rendering, and the normal call that handles the rest.

I have to investigate this further before committing to any course of action - and due to the extent of the possible changes required - it may end up being an 0.8.0 thing. Also, note that this affects all engines and APIs that use this technique to render to texture.

CE.

[grifos]

One way to solve this problem is to render the GUI two times.
On before the Irrlicht scenegraph rendering and one after.
I'll explain. The flicker seems to appear when the texture from the GUI need to be redrawn (so when there is a mouse hover, a news input in an edit box, a scrolling, etc...). However the texture are not redrawn every frame, in fact in the CEGUI::System::getSingleton().renderGUI(); function there is a test to check if the texture must be regenerated. If not they are simply applied on the current front buffer. If they must be regenerated it goes using the irrlicht RTT method and that clear the front buffer (Like Crazy Eddie said).

So if you call CEGUI::System::getSingleton().renderGUI(); before rendering your Irrlicht scenegraph then recall CEGUI::System::getSingleton().renderGUI();. Then they are generated and applied (which is not necessary but we can't do anything about it) the the scenegraph is rendered and finaly the GUI is once again applied without regenerating any of the used texture.
Just remember with this methode that you mustn't inject any event nor force the redraw of any window between the Irrlicht scenegraph rendering and the second gui rendering call.

I hope this helped

bye

[grifos]

The best way I think to correct this bug without changing to much code would be to have 2 differents functions.
One that could be called preRender and whit the aim to recreate the Gui's texture if needed.
The other would be the renderGui.

Regards

[CrazyEddie]

Hi,

Yes, indeed, this will certainly be the solution. I've not looked into it at all yet, since it should be possible to combine that work with other changes needed to get 'multiple roots' working (at least that's the plan!).

Thanks for confirming that the 'double call' of renderGUI fixes the issue in the interim. For the final solution, as they say... watch this space!

CE.

[Timo]

Maybe I'm missing something crucial here... but I think the easiest way to fix this is to not clear the framebuffer every time a render target texture is deactivated:

Code: Select all

--- CEGUI-0.7.1\cegui\src\RendererModules\Irrlicht\CEGUIIrrlichtTextureTarget.cpp   Thu Sep 24 21:14:22 2009
+++ CEGUI-0.7.1-mod\cegui\src\RendererModules\Irrlicht\CEGUIIrrlichtTextureTarget.cpp   Wed Feb 17 10:28:56 2010
@@ -67,7 +67,7 @@
 void IrrlichtTextureTarget::deactivate()
 {
     IrrlichtRenderTarget::deactivate();
-    d_driver.setRenderTarget(0);
+    d_driver.setRenderTarget(0, false, false);
 }
 
 //----------------------------------------------------------------------------//
@@ -81,7 +81,7 @@
 {
     d_driver.setRenderTarget(d_texture, true, false,
                              irr::video::SColor(0, 0, 0, 0));
-    d_driver.setRenderTarget(0);
+    d_driver.setRenderTarget(0, false, false);
 }
 
 //----------------------------------------------------------------------------//


I've been using this with irrlicht 1.6.1 (OpenGL) and haven't encountered any problems.

[CrazyEddie]

This could well be a solution; I'm certainly no expert on Irrlicht so it's entirely possible / likely that I missed the simple solution Thanks for the input here - I'll try it out

CE.

[agamemnus]

-.-

I'm not very amused that I had this problem to begin with. I thought this library was more developed than that to have issues like this. Thankfully, I found this thread on google and will be using Timo's code. (edit: compiled and works beautifully!)

[CrazyEddie]

I'm not very amused that I had this problem to begin with.

It has never been our aim to amuse people.

I thought this library was more developed than that to have issues like this.

Shit happens. Get over it, and move on.

CE.

[Jamarr]

I love crazy eddie...

agamemnus, I don't understand why you would whine about a library having a bug in it. Especially after having received plenty of assistance from CE and others in figuring out your own user errors. No one is perfect, no code is perfect. The sooner you realize that, the happier you'll be in life. Like everyone else on these forums, you should be greateful that an open-source and royalty-free GUI library as good as CEGUI even exists.