Viewport lockup perhaps due to uninitialized texture

[greebo]

Here's another package, this time with GTK+ 2.12.11 from July 2008. Is there error already there in this version?

 

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

[Constantine]

Here's another package, this time with GTK+ 2.12.11 from July 2008. Is there error already there in this version?

 

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

Yes, the viewports hang.

[greebo]

Crap. <_>

[greebo]

Here's another Win32 test version with some glGetError() calls enabled in the render routines.

 

http://www.bloodgate.com/mirrors/tdm/pub/d....0.9.10pre2.zip

 

Constantine, Sneaksie and anybody else with that viewport problem: please check this out if there are any useful error messages occurring with this build when the lockup happens.

[SneaksieDave]

No luck unfortunately. Note though that there's no total lockup; you can still use the editor enough to exit gracefully, it's just that the viewports have gone dead. So perhaps the opportunity isn't there for the editor to crash and say "hey this happened..." I'll post the tail end of the log just in case.

 

I don't know if this is any help, but I can say that the last version I've tried which doesn't experience this problem is .9.9pre2, which I think was the last version before the mediabrowser pre-load changes. However disabling pre-load doesn't fix it.

 

I'm trying to pin down the exact steps a little closer and I'm finding the following interdependent conditions:

 

1. It is required that a texture be selected at some point in the media browser.

 

If I do not select a texture, I can select, deselect, drag the view around all day, looking at the same cube, and no problem occurs. In contrast, After selecting a texture, if I do either of the following two things in condition 2, I get the lockup consistently.

 

2. It occurs when I press CTRL (as in dragging the view around in cam-mouselook mode) or shift while the cam view has focus.

 

condition 1: drag around the view (cube not selected) with press of CTRL in cam-mouselook mode (after RMB), or

condition 2: select the cube with press of shift-click

 

So it happens in both cases upon hitting an accelerator key. Conflict?

 

3. Assuming the texture selection (condition 1) has taken place, it is not required that geometry exist and be in view.

 

I previously thought it was necessary, but that was incorrect. CTRL view dragging in cam-mouselook mode are apparently fine without geometry. In contrast, pressing shift while in cam mode causes the problem.

 

 

In case my explanation here is not very good or is confusing, here is my summarized take on it: something very bad is happening upon selecting a texture in the media browser (turns out mmb copy-shader is not necessary for this). If no texture is ever selected, no problem ever occurs. After (and only after) this condition is met, the end game is brought about by the press of accelerator keys while the cam has focus. If accelerators are not pressed, you can look around the port all day without problem. As soon as shift (for selection) or CTRL (for view dragging) is pressed, the ports are dead. The bottom line is though, both conditions above must be met.

 

 

Here's the log, though it doesn't look significant. Console reports nothing different from without the problem either.

[snip]
GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control 
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: 321Definition not found: 
[shaders] Unable to load texture: _default
brushDragNew
[shaders] Loaded texture: _white
[shaders] Loaded texture: textures/darkmod/carpet/rugs/ornate_black_gold01
[shaders] Loaded texture: textures/darkmod/carpet/rugs/ornate_black_gold01_ed
ToolbarManager: Instantiating toolbar: textool
OpenGL window configuration: colour-buffer = 32bpp, depth-buffer = 32bpp
setShader
LayerControlDialog shutting down.
SurfaceInspector shutting down.
PatchInspector 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
XMLRegistry Shutdown: 691 queries processed.
XMLRegistry: Saved user/ui/filtersystem/filters to C:\Documents and Settings\user\Application Data\DarkRadiant\/filters.xml
XMLRegistry: Saved user/ui/colourschemes to C:\Documents and Settings\user\Application Data\DarkRadiant\/colours.xml
XMLRegistry: Saved user/ui/input to C:\Documents and Settings\user\Application Data\DarkRadiant\/input.xml
XMLRegistry: Saved user to C:\Documents and Settings\user\Application Data\DarkRadiant\/user.xml
EventManager successfully shut down.
Closing log file at Sun Jan 25 10:32:27 2009

[greebo]

Hm, thanks for these observations. I looked through the log but actually there was too much happening in between 0.9.9pre2 and the next Win32 build.

 

If you're inclined to do that, I can perform a series of counter-tests. I'll revert the code to the state as it were in 0.9.8, and then try to upgrade the new GTK+ 2.14 headers. If it was a change in our code, this build should still work. If it still fails, it's most probably GTK-related.

 

I won't be able to do that today, I'm afraid, I need to think about the least time-consuming way to do those tests. You would need to download a series of files and test them - would this be ok for you?

[greebo]

One more before I go to sleep: here's one build with one minor change in the MediaBrowser code. I don't think this was the cause, but I want to make sure to check that remote chance:

 

http://www.bloodgate.com/mirrors/tdm/pub/d....0.9.10pre3.zip

[Constantine]

I have a guess why it happens.

 

I think the lower info panel is cause of the lockups.

 

First, it is enough to press shift to make a lockup (without clicking with a mouse on anything). When you press shift, DR tries to display some info on this panel and it stretches in width. Everything goes OK while no default texture selected in the shader clipboard and the panel width doesn't exceed screen width.

 

When some texture is selected, the panel lengthens by a distance depending of shader name length. When you press shift, the panel lengthens some more and its width can exceed screen width. In this case the lockup happens.

 

The probability of a lockup depends of screen resolution, system font size (96 or 120 dpi), and the shader name length you currently selected.

 

The lockups happen only when DR window maximized. Try to unmaximize the window and press shift and you can see how the window stretches and it can exceed the screen bounds (in lower resolutions and when some material with a long name selected). In this case, maximize the window and you can get the lockup by pressing shift.

[greebo]

Very interesting. While I cannot reproduce the viewport lockup when switching to 1024x768 and pressing shift, I definitely see the main (background) window not redrawing anymore, as Fidcal reported earlier.

 

My native resolution is 1920x1200, which probably explains why this never occurred to me.

 

I'll have to some more tests to see whether I can do anything about this.

[Constantine]

Very interesting. While I cannot reproduce the viewport lockup when switching to 1024x768 and pressing shift, I definitely see the main (background) window not redrawing anymore, as Fidcal reported earlier

Is your console window open when you're pressing shift?

The lockup never occurs when the console window is in focus. You should click on the main window in this case before pressing shift.

[greebo]

No, I didn't have the console open when I tried. I assume in this case the textview widget would be eating the Shift, Ctrl and Alt modifier events, that's why the lockup is not triggered.

[SneaksieDave]

You would need to download a series of files and test them - would this be ok for you?

Absolutely. Trying the first one from yesterday momentarily.

 

Also I can confirm what Constantine is saying. If DR is not maximized, I don't get the dead ports. And even more interesting: if I am maximized and do cause the problem, I can d-click the title bar to exit maximized view, and the problem is fixed. We're gettin' there...

 

Another interest tidbit is that if I'm going maximized to not, back and forth, entering cam mode and selecting/deselecting the cube, all can be fine, as long as I don't click a new texture in the media browser. Once I do, maximized view will again experience the problem. I believe this lends some evidence to what Constantine is saying as well, since it changes the lower tray (so it correlates, but we must be careful it's not a red herring).

[greebo]

I have an attempt here to fix this problem, please check it out:

 

http://www.bloodgate.com/mirrors/tdm/pub/d....0.9.10pre4.zip

[SneaksieDave]

I tried pre3 above without success, still got the problem. Now downloading pre4.

[SneaksieDave]

Interesting, so far I haven't come across the problem. Will try to throw more things at it to see if it's really gone. One bad thing to note: for some reason I got a completely out of the blue crash just after startup, the first time. I launched, and then started to adjust the size of my view ports, and DR bombed out. So far, a few attempts to repro haven't succeeded...

[greebo]

@Constantine: did you get a chance to test the pre4 package? Does the error still occur for you?

[Constantine]

@Constantine: did you get a chance to test the pre4 package? Does the error still occur for you?

Everithing works fine for me in pre4! I haven't seen any lockups or crashes.

[SneaksieDave]

If it makes any sense, one thought on the crash I had is maybe something was off in the ini? I dunno. I do a diff each time I install a new version, between my current build's original ini and the newest build's original ini, to determine if I can drop my old ini into place for the new build (e.g. if no changes are made, it's the same and I can retain my settings). So, since I was changing maximized and not, changing slider positions for both modes back and forth, and probably shutting down in odd settings, maybe it crashed because it didn't like some value in my ini? It did happen when I moved the cam port divider. Who knows; so far it hasn't happened again.

 

Though I'm cautious not to call the beast slain prematurely, what was the root of the viewport problem?

[greebo]

Though I'm cautious not to call the beast slain prematurely, what was the root of the viewport problem?

I'm pretty confident that it was as described by Constantine: the status bar contents were getting too large on lower resolutions, which usually is not a problem if the window is not maximised (the window is just resized to fit) or the screen resolution is wide enough. Though for maximised windows, the code for the GtkTable was obviously hanging due to some bug in GTK 2.12+. This bug was not there in previous GTK 2.10 (the one we've been using for years), so this is only a problem related to newer releases.

 

I could also produce some sort of "hang" on my system, after reducing the resolution to 1280x800 and typing in an artificially long shader name, plus pressing shift. When the window was maximised, it stopped redrawing properly. The menus were still reacting, but the screen updates for the toolbars and status bars were stopped. It was not affecting the orthoview or the camera, but it was a reproducable hang. I guess the actual behaviour is undefined, that's why the symptoms were different on the various systems.

 

I did a small change to the status bar packing code, and now it's not trying to squeeze the parent window wider than it can get when maximised - problem circumvented.

[SneaksieDave]

Nice! :thumb: