strange painting effect when resizing framewindow

[Tiresias]

Hello

i have a killing me softly issue with the 7.1 cegui only.
In one of my PC, when resizing my windows, there are painting artefacts : more or less if i resize diagonal wise (both horizontal and vertical at same time), after some dimension is reached i can see that it is like a portion of the window is tiled over the whole window surface. see screenshot.
http://www.Outremondes.com/killingMeSoftly.JPG

Problem is that it happens only on one PC out of 3.

Where shall i look to try to debug this? is there a function in cegui i could look at where is done the window rendering?

I just need a starting point because right now i have no f....g idea Or maybe someone faced something similar?

(with cegui 6.2 it all working fine).

I must say that both release and debug version shows same issue. As well once this issue happen it happens on most of the windows.

wake up

first :
09/05/2010 20:23:35 (Std) * -------- START OF ESSENTIAL SECTION TO BE POSTED ON THE FORUM -------- *
09/05/2010 20:23:35 (Std) ********************************************************************************
09/05/2010 20:23:35 (Std) ---- Version 0.7.1 (Build: Feb 6 2010 Debug Microsoft Windows MSVC++ 9.0 32 bit) ----
09/05/2010 20:23:35 (Std) ---- Renderer module is: CEGUI::OpenGLRenderer - Official OpenGL based 2nd generation renderer module. TextureTarget support enabled via WGL_ARB_pbuffer. ----
09/05/2010 20:23:35 (Std) ---- XML Parser module is: CEGUI::ExpatParser - Official expat based parser module for CEGUI ----
09/05/2010 20:23:35 (Std) ---- Image Codec module is: SILLYImageCodec - Official SILLY based image codec ----
09/05/2010 20:23:35 (Std) ---- Scripting module is: None ----
09/05/2010 20:23:35 (Std) ********************************************************************************
09/05/2010 20:23:35 (Std) * -------- END OF ESSENTIAL SECTION TO BE POSTED ON THE FORUM -------- *

[CrazyEddie]

Strange issue. I wonder what, if any, differences there are between the video hardware and drivers on the machines which work and that one which doesn't? Is the RTT technique used for all machines the same, or are the working ones using FBO? Basically, I suspect a possible bug in the WGL_ARB_pbuffer code since this does not get tested quite so extensively, once you confirm the other details I look into that and hopefully get a fix in ASAP (if it is that).

The only other thing that springs to mind is something to do with state settings, though we might expect that to have affected all the machines.

CE.

[Tiresias]

Hello
thanks for reply,
the video cards are diferent on the pcs.

on my working laptop video card is ATI RADEON XPRESS 200M (integrated)
on my failing laptop video card is ATI MOBILITY RADEON 7500,
both have their latest drivers,

as if one is using RTT or FBO no idea how could i check this?

i launched glintercept but didnt capture error ,

[CrazyEddie]

The info is available in the log, for example in the log you posted, it's indicated in the following line:

Code: Select all

09/05/2010 20:23:35 (Std) ---- Renderer module is: CEGUI::OpenGLRenderer - Official OpenGL based 2nd generation renderer module. TextureTarget support enabled via WGL_ARB_pbuffer. ----

So in this case we know it's using WGL_ARB_pbuffer.

CE

[Tiresias]

computer says: no

seriously the working pc shows:

"TextureTarget support enabled via FBO extension" !!!

so maybe you found something ... pcs are not using same rendering, faulty pc is using WGL_ARB_pbuffer ....

[CrazyEddie]

Thanks for confirming that, I will test this later on today and also tomorrow (when I can get access to ATI hardware).

CE

[CrazyEddie]

To update on this issue: so far I have tested WGL_ARB_pbuffer on my main windows install and can report no issues appear to be present there. I have yet to test on ATI hardware, that will be this evening. Hopefully the issue will show up, and I get get it fixed

CE.

[Tiresias]

it is not that easy to reproduce, you may have to create several windows and make them overlap, then resize them etc
if u cannot reproduce it i can have a look to this rendering function as i can reproduce it (if bug there is...)

[CrazyEddie]

Ok, as you suggested may be the case, I did not successfully reproduce this issue (I did spot something else, so that was good!)

If the issue is related to the WGL pbuffer implementation of texture target, as I suspect, then the file you need to concentrate your debugging efforts on is probably cegui/src/CEGUIOpenGLWGLPBTextureTarget.cpp. Let me know I can assist in any other way

As an extreme long shot: do you have the enableExtraStateSettings in the GL renderer set to true?

CE

[Tiresias]

i am not using the extrasetting to true,
i activated it doesnt change anything ...
i will look at this file but as i m no opengl expert i may not find a lot
wll let u know

[Tiresias]

ok i investigated this file and i can say that problem occurs when i resize my window more than 512x512.
in this scenario cegui tried to initialise the PBuffer with ideal dimension 1024x1024 but when querying the actual Size
(calling wglQueryPbufferARB) it gets only 512 512.
Then you call d_CEGUITexture->setOpenGLTexture(d_texture, d_area.getSize()); with the d_area being set to 512 512,
then i stopped looking further see if you can find yourself something,
please let me know if u need more info its easy to reproduce here !

[Tiresias]

creating the openglRenderer with the type "TT_NONE" solve the issue ....

i am concerned about perf though, i think you have pretty much info ur side, please ping me if u need more info i ll collect it)

[CrazyEddie]

Thanks for this information, it gives me a concrete starting point to - hopefully - resolve this issue. I'll let you know how things go; I will likely be working on bugs and such over the coming weekend, so hopefully progress will be made then

creating the openglRenderer with the type "TT_NONE" solve the issue ....

i am concerned about perf though

With regards to this, if you use TTT_FBO instead of TTT_NONE, you can kind of get the best of both worlds because the system will then use FBOs for rendering to texture if available but fall back to none if FBOs are not available. Or to put it another way, will disable only the use of the pbuffer method - so for most cases you'll still get the render texture caching, unless it would cause these potential issues

CE.