Viewport lockup perhaps due to uninitialized texture

[SneaksieDave]

Didn't want to make an issue for this yet until it can be confirmed it's not just me (shouldn't be, as it is new, but who knows). Also, it's important enough that it be here for visibility:

 

-start DR anew

-draw a cube

-in the cam port, MMB it, to copy the default texture to clipboard (apparently essential)

-ESC to de-select the cube (apparently essential)

-shift click the cube to (re) select it (essential)

 

At this point, the viewports are reproducably dead. You can still exit DR gracefully, but the viewports have that effect where they can't draw anymore, so anything dragged across them remains (see image for demo). My guess is this results from some uninitialized state or such from the recent change allowing preload of the media browser.

 

 

Edit: Actually for me, this seems to be a complete showstopper. I assumed that a workaround would be to not copy to clipboard, or to load multiple textures (assuming it was a "first time only") type of thing, but I can't seem to get around this problem.

[greebo]

Can't reproduce that, neither in Vista, nor in Windows XP. Anybody else got this?

[SneaksieDave]

Crud. Well I'll be able to try it on my game system shortly, to see if maybe it's this system (though it doesn't happen with the previous rev).

 

Does this help at all?

 

[snip]
OpenGL window configuration: colour-buffer = 32bpp, depth-buffer = 32bpp
OpenGL window configuration: colour-buffer = 32bpp, depth-buffer = none
OpenGL window configuration: colour-buffer = 32bpp, depth-buffer = none
OpenGL window configuration: colour-buffer = 32bpp, depth-buffer = none
ToolbarManager: Instantiating toolbar: texture
OpenGL window configuration: colour-buffer = 32bpp, depth-buffer = none
EventManager: Shortcuts found in Registry: 320Definition not found: 
[shaders] Unable to load texture: _default
brushDragNew
LayerControlDialog shutting down.
BrushModuleClass::shutdownModule called.
Doom3EntityCreator::shutdownModule called.
EntityClassDoom3::shutdownModule called.
EventManager: shutting down.
ObjectivesEditorModule shutting down.
RadiantModule::shutdownModule called.
filesystem shutdown
Doom3ShaderSystem::shutdownModule called
[snip]

[SneaksieDave]

Uh oh. Confirmed to happen (once so far*) on my game system. Trying to get consistent repro, but so far it seems hit and miss. Which I suppose suggests maybe some memory being clobbered?

 

Will keep investigating. At least it's less likely to happen on this system. On my test machine, it happens each time. Test machine is XP Pro SP3, up to date; this system XP Pro SP1. And of course has the redistributable installed (or it wouldn't run at all).

 

 

Edit: * twice

[SneaksieDave]

Can someone (anyone) with win32 release please try this? I'm doubting it's unique to me, as it happens across two very different XP systems. DR is unusable for me (unless it doesn't happen, as on my game system where it is less frequent) as a result of this. The randomness of it makes me think memory violation.

[New Horizon]

I can confirm this issue too.

[SneaksieDave]

Here are a couple of demo videos showing it happen.

 

First vid: http://www.filedropper.com/badtex1

-draw a cube and drag it into view

-deselect with ESC

-click ortho port (no specific reason, but maybe important focus shift)

-MMB cube in cam port to copy texture to clipboard

-attempt to shift click select the cube and fail; try again, fail; can enter and exit mouselook mode

-bring up exit dialog to show that viewports are "dead"

 

Second vid (different method): http://www.filedropper.com/badtex2

-draw a cube and drag it into view

-choose a texture in the media browser, apply to selected cube

-RMB cam port to enter mouselook mode

-After a second or so, the viewports die again as demonstrated

 

 

Edit:

I can confirm this issue too.

Whew! Thanks, glad I'm not being singled out.

[Fidcal]

Can't get this to happen in 64 bit version in Vista but I get another problem that I don't know what situation causes it yet. I get the background won't redraw. This makes the buttons and menus unusable. I found today they redraw if I UNmaximize then restore the main window (quicker than reloading) You might try that as a temporary fix?

 

[EDIT] I guess I mean from maximized, restore down then re-maximize.

[greebo]

Tried to reproduce this in WinXP using the package from the website on angua's machine (for almost 20 minutes now) - no luck so far.

 

I'm somehow afraid that the f*cking GTK binaries in Windows have one of those bugs again - I can try to revert the binaries to the old GTK+ 2.8 we've been using for years now, but this is a somehow blind shot.

[greebo]

Here's DR 0.9.9.1 with the old GTK+ binaries. Does this work at all for you and if yes, is the issue still there?

 

http://www.bloodgate.com/mirrors/tdm/pub/d...1.gtk2.10.8.zip

[SneaksieDave]

Here are results of a handful of tests using the same exact steps with the gtk2 zip you provided, and the 0.9.9.1 release. Steps:

 

1. launch fresh

2. draw a cube in view

3. MMB to lift the texture to clipboard

4. ESC to deselect

5. shift click to reselect

6. drag the cam view around a bit

[and if that hasn't already caused the problem (and it doesn't usually on my game system)]

7. open the Media browser, and browse to the first rug in darkmod

8. Apply to selected

9. drag the cam view around a bit

 

The results (if the problem occurred):

 

gtk2zip - no

.9.9.1rel - yes

.9.9.1rel - yes

gtk2zip - no

.9.9.1rel - yes

gtk2zip - no

gtk2zip - no

.9.9.1rel - yes

.9.9.1rel - yes

gtk2zip - no

gtk2zip - no

 

So it's a pretty resounding yes, this is related in some way to the new gtk libraries. I dunno if that's good news, or bad...

[greebo]

That's bad news of course, because this is now the third time I've been trying to move on to a newer GTK binary version and each time something different just went out of order. Screwit.

 

Now I can only cross my fingers that the next GTK release somehow supports the GL widgets in a better way or stick with the three year old binaries forever. Or compile GTK on my own from source and see where it fails.

 

I'll also try to create a package with GTK+ 2.14.6 (which was released two or three weeks ago) to see whether this changes anything. It also bothers me that this only happens in Win32, and not on all systems either.

[greebo]

I have a new ZIP package for testing:

 

http://www.bloodgate.com/mirrors/tdm/pub/d...1.gtk2.14.6.zip

 

This is using the most recent GTK+ DLLs, please check it out.

[SneaksieDave]

Sorry for the delay. On my more troublesome work PC, this latest package does not help the problem. On first try, I got the lockup from the first steps in the sequence (MMB, Esc, then select -- freeze). I guess this is probably confirmation that it doesn't help, but I could also try my game system in a while if you prefer.

[Constantine]

 

I installed DarkRadiant 0.9.9.1 today (after reinstalling WinXP) and found that it hangs when I load an existing map and try to select something (nevertheless, when I create a new map, I can create and select objects rightly, but until I save and load it).

 

After that I had to revert to DR 0.9.8.1 - it works properly.

Exact reproduction steps?

 

Is this related to the "Viewport lockup" issue as described in the other thread?

 

Yes, it looks like it's the similar problem, although the steps to reproduce it on my PC are a bit simpler:

 

1. Start DR

2. Open any existing map

3. Click on any brush/model/entity with Shift

4. Nothing changes in the viewports, they don't react to the mouse, but the menu is still working (for example, I can open another map).

5. I've noticed also that If I minimize DR window and maximize it again, the viewports return to life, I see the map with selected primitive, I can manipulate it and everything goes OK until I try to select another primitive again.

 

I've tried using package with GTK 2.14.6 and had no luck.

 

EDIT:

greebo, could you please resurrect the link to DR with GTK 2.10.8? I'd like to try it.

[greebo]

The link above should be active in a few minutes again. If not, please drop a note here.

 

I'm pretty fed up with these GTK issues in Win32, I must say.

[OrbWeaver]

I'm pretty fed up with these GTK issues in Win32, I must say.

 

I wonder if it's more GL related, than GTK? It is possible to put in debug lines for OpenGL, by using glGetError() etc at strategic points. Maybe some of our texture handling is incorrect.

[greebo]

Hmmm, could be possible, of course. It's just the fact that merely changing the GTK+ binaries fixes the issue seems to indicate that the error is not on our behalf, somehow.

 

@SneaksieDave: does this "not redrawing" issue occur with the Texture Tool as well?

[Constantine]

The link above should be active in a few minutes again.

I've tried it. DR works OK with this GTK version.

[greebo]

It seems like the next Win32 version of DarkRadiant will need the old GTK binaries then, to reduce these types of incidents until we figured out what the heck is going on.

[SneaksieDave]

@SneaksieDave: does this "not redrawing" issue occur with the Texture Tool as well?

Interestingly, perhaps not (see image). I opened the texture tool, and then did the normal steps to cause the problem. Although I couldn't confirm that the texture tool still "worked" (because one of my steps is to select the cube, which then deselects the face, so the texture tool has no valid object), after the problem occurred, I dragged around the exit dialog as usual to demonstrate the problem, but as you can see, the texture tool was still getting redraw updates.

[greebo]

Hm, that might actually be an indication that it's not only GTK's fault, but also one of the way GL calls are issued.

[greebo]

@SneaksieDave: please remind me to assemble a new package with a different GTK+ version. I'm going to make a few tests to narrow down where in the GTK+ version history things went wrong.

 

As long as I can't exactly reproduce the error on my own machine, it probably is not worth building GTK from source to inspect the issue, so I'll have to look into the method above.

[SneaksieDave]

Would you like a bugtracker entry for it? I could set it highest priority so that it doesn't escape notice.

 

Also, for repro, maybe a win32 partition or image would help? Do we know yet that it is win32 + GTK causing it?

[greebo]

I have a Win32 test system available - angua's laptop, which is running XP SP3, but the error doesn't occur there so far. I'll have another look.