The latest SVN bugs thread

[CuteAlien]

In COpenGLCallBridge::setTexture there was this "Texture[stage] != Driver->CurrentTexture[stage]" check added some time after 1.8 (been there for some time). This does cause some rather evil bugs. The problem is that Texture[stage] is keeping raw pointers without reference-handling and so it's not reset when a texture is deleted. So when a new texture is created at the memory of a previously deleted texture this check can fail when it shouldn't. Resulting in all kind of weird errors like unlock() calls failing to update textures and so on. As it's about memory management it happens rather randomly (I had a noticeable effect in around 1 of 5 starts of my application - each time in another place... drove me pretty crazy last night ^_^).

My solution would be to remove the check completely and just live with the additional glBindTexture calls.

If someone thinks it's absolutely necessary, for example because it's causing a huge speed-hit then I'm open for other ideas. For example we could try to make a memory-management like with COpenGLDriver::CurrentTexture, but I'm a little afraid of accidentally causing situations where textures are not deleted. Or we could force resets for COpenGLCallBridge::Texture in the COpenGLTexture destructor (not sure which troubles that would cause - looks somewhat ugly). Could maybe be done by adding a new function to the COpenGLDriver which does the real texture removing, so it does the glDeleteTextures and resets all caches and this is then called from the COpenGLTexture destructor (hm, that wouldn't be too bad I guess).

I'm also not sure if the COpenGLCallBridge::setActiveTexture and COpenGLCallBridge::setClientActiveTexture are correct. Basically they do the same thing - just with GLenum texture id's. This didn't fail in my tests so far - so maybe those are for example created in increasing order by opengl in which case they would likely never fail (one could create a pathological case which causes a wraparound, but we can ignore that). If OpenGL does not guarantee increasing texture id's then those functions are wrong as well and ActiveTexture and ClientActiveTexture also need a reset when a texture is deleted.

[Nadro]

I'll fix invalid pointer issue. We can't remove "if" from this method, because we call this method really often. COpenGLCallBridge::setClientActiveTexture is related to fixed function texture coordinates, so both methods must exist, because they are related to different things.

[CuteAlien]

The question is if the if is really speeding up things much. Current solution which I use for workaround does this:

Code: Select all

 
else if(Driver->CurrentTexture[stage])  
{
    glBindTexture(GL_TEXTURE_2D, static_cast<const COpenGLTexture*>(Driver->CurrentTexture[stage])->getOpenGLTextureName());
    Texture[stage] = Driver->CurrentTexture[stage];
}
 

Depends on how expensive glBindTexture really is. If that just set's an integer then it's not more expensive than the if check itself. If it does crazy stuff internally then it might add a real cost.

[CuteAlien]

Ah - I didn't mean to remove setClientActiveTexture. I get that they are both needed - what I meant to say is - they might have a bug which is more or less of the same kind than the bug in setTexture. Aka - they both check against a variable which is not reset when the texture is deleted. So if texture-id's are re-used by opengl then those functions are both buggy as they are.

[Nadro]

OpenGL methods overhead is depend on drivers implementation (it's not just set an integer), however glBindTexture isn't the cheapest method, so it's good to avoid unnecessary calls in this case.

Yes, both methods are buggy. I'll try to send a patch today.

[hybrid]

Didn't we fix this issue in the old version of OGL calls by using reference counting? Has been fixed at least once or twice for what I know, so please use the "proven solution".

[CuteAlien]

@Hybrid: That solution is still there as well. This is now additionally. As I mentioned - could in theory be handled similar maybe - thought not completely trivial maybe (not sure if ref-counting really is the best in this case). Also that one was slightly different as the removing there happened already in the driver - while this one is about removing the texture itself (outside the driver).

[Nadro]

Fixed in trunk. I'll prepare similar fix for OGL ES2.

BTW. Sorry for my mistake, in my previous post I agreed that COpenGLCallBridge::setClientActiveTexture is bugged too, but it's not a true. After back to home I checked this method and it's fine, it sets just an active fixed pipeline texture coords and like a COpenGLCallBridge::setActiveTexture it's not related to ITexture memory stuff.

[CuteAlien]

Right - I thought the parameter for setClientActiveTexture is a texture-id, but just looked again and it's certainly not. So no problem there. Thanks for the fix - looks good on first view.

edit: Just did run my tests and the problems are gone.

[christianclavet]

Hi, I'm compiling the application on Ubuntu now (SVN trunk - Ubuntu 14.04 LTS 64bit) and something is strange in the way the window is created.

The windows open like at 0,0 and I can't move the windows (since I can't access the top of it that is hidden by the Ubuntu menu bar)
I was able to move it by stretching the window to take the full screen, then the window "popped" out of the Ubuntu menu bar).

When I saw that behavior, I decided to try to maximize the windows when it is created like this: (using a createdeviceEx() to open it)

Code: Select all

device->maximizeWindow();

The windows now is not maximized but is positionned on the lower right side of the screen, this time at least I can grab the windows title bar and move it and have access to the buttons (minimize, maximize and close)

Is it something in Ubuntu that does now or changes in the creation of the device on Linux?
EDIT: Wow, something changed, I only recompiled it again and it's getting stuck again on the upper left hiding the window top. Put the maximize windows inside the update loop to be sure it getting maximized, and there is nothing changed. Is that command is ignored on Linux?

[CuteAlien]

Yeah, maximizeWindow doesn't seem to do anything on X11. Not sure about original positioning - I thought the WindowManager does that - but maybe applications can give hints. Can't reproduce that right now on Ubuntu.

On the other hand I get all kind of crashes and textures missing on Ubuntu right now with trunk - have to check when that has started (1.8 still works, so I guess it's our fault).

[CuteAlien]

OK, my crashes and texture-troubles had been cause by new libjpeg not re-compiling correctly until I did a 'make clean' first. Works now.

And I can reproduce the problem on Ubuntu by opening the same application over and over. It get's a new position each time - and for some reason it's sometimes inside the toolbar. Other apps don't seem to do that, so I guess there is some way we can avoid it. But needs more research (any hints welcome...).

[christianclavet]

Thanks CuteAlien, was really not sure what was happening there.

Perhaps investigating how Irrlicht open a window on Linux, and see why it's positioning the windows almost randomly. Find it strange that maximize and minimize methods are not working. Is this behavior is from the beginning? (never tried using theses method on Linux before today).

Really happy that you were able to reproduce the problem on your end.

[hendu]

The WM decides the window position - you should file a bug for the WM (Unity?). Irr passes 0,0 for the position, and only forces it when fullscreen.

Minimize, maximize - minimize works fine for me, but maximize is implemented as a restore, so it does exactly what the code tells it to. It would need optional netwm support to send maximize events properly.

Again, if Unity doesn't respect XIconifyWindow (the minimize event), that's a bug in Unity.


edit: google gives several results for unity positioning windows badly:
http://ubuntuforums.org/showthread.php?t=1790555
http://askubuntu.com/questions/170377/w ... e-menu-bar

edit2: and several reported bugs about unity ignoring the minimize, hah:
https://bugs.openjdk.java.net/browse/JDK-8012224

[CuteAlien]

Yeah - the WM decides it usually. But I tried it with several applications and couldn't reproduce the problem except with the Irrlicht applications. I'm sure there are more apps out there which go wrong - but given that most don't have the problem it seems like there should be some way we can prevent it.