Circular module dependency

[OrbWeaver]

In the course of investigating GL issues I have encountered a crash which seems to occur because there is a circular module dependency. I'm not sure how this ever worked, since nothing I have changed so far involves module dependencies (AFAIK), unless it was just by chance:

 

ModuleRegistry: preparing to initialise module: Radiant
  Radiant needs dependency Clipper
ModuleRegistry: preparing to initialise module: Clipper
  Clipper needs dependency CommandSystem
ModuleRegistry: preparing to initialise module: CommandSystem
  CommandSystem needs dependency XMLRegistry
ModuleRegistry: dependencies satisfied, invoking initialiser for CommandSystem
CommandSystem::initialiseModule called.
=> Module CommandSystem initialised.
  Clipper needs dependency EventManager
  Clipper needs dependency PreferenceSystem
  Clipper needs dependency Radiant
  Clipper needs dependency XMLRegistry
ModuleRegistry: dependencies satisfied, invoking initialiser for Clipper
Clipper::initialiseModule called
=> Module Clipper initialised.
  Radiant needs dependency CommandSystem
  Radiant needs dependency EntityClassManager
ModuleRegistry: preparing to initialise module: EntityClassManager
  EntityClassManager needs dependency ShaderCache
  EntityClassManager needs dependency UIManager
ModuleRegistry: preparing to initialise module: UIManager
  UIManager needs dependency CommandSystem
  UIManager needs dependency EventManager
  UIManager needs dependency Radiant
  UIManager needs dependency XMLRegistry
ModuleRegistry: dependencies satisfied, invoking initialiser for UIManager

 

Note that Radiant needs Clipper and Clipper needs Radiant (I thought we got rid of the Clipper module anyway?). Also Radiant -> EntityClassManager -> UIManager -> Radiant.

 

Greebo, do you have any suggestions for the easiest way these circles could be broken?

[greebo]

In the course of investigating GL issues I have encountered a crash which seems to occur because there is a circular module dependency. I'm not sure how this ever worked, since nothing I have changed so far involves module dependencies (AFAIK), unless it was just by chance:

I think we talked about this once in the past, and as far as I can recall there are modules which are using each other in their respective public methods. The only reason it's working is due to the fact that most public functions are not called before all modules are properly initialised anyway (as in the Clipper's case, nobody is clipping anything before the whole application is started up). So usually these circular dependencies are not a problem, but obviously you're getting crashes.

 

Note that Radiant needs Clipper and Clipper needs Radiant (I thought we got rid of the Clipper module anyway?). Also Radiant -> EntityClassManager -> UIManager -> Radiant.

 

Greebo, do you have any suggestions for the easiest way these circles could be broken?

The Clipper module calls GlobalRadiant().updateAllWindows() which can be changed to radiant::getGlobalRadiant().updateAllWindows(), then the MODULE_RADIANT dependency can be removed. This solves this particular case, but I'm not sure about the UI Manager, probably something similar.

[OrbWeaver]

I think I might have been barking up the wrong tree with the circular dependency issue; I remember our previous discussion now and I agree that this should not be a problem if the circular function calls are restricted to methods which will only be used after all modules are initialised.

 

The actual crash I was getting was caused by GlobalRadiant() returning a null pointer, which should never happen as far as I know. It is not happening any more, with the only change being that GlobalRadiant() no longer caches the return value in a static variable, but again this might be another irrelevance. The current intention is to replace GTKGLext with GTKGL/GTKGLArea in the hope of fixing the issues with rendering on a composited desktop, but I can't see how this could affect the module system unless there is some tricky library linkage issue going on.

[greebo]

The current intention is to replace GTKGLext with GTKGL/GTKGLArea in the hope of fixing the issues with rendering on a composited desktop, but I can't see how this could affect the module system unless there is some tricky library linkage issue going on.

Ah, there is a replacement for GtkGLExt? Sounds interesting, as gtkglext is not maintained anymore, last time I checked.

[OrbWeaver]

Yes, previously GtkGLArea was unmaintained, now it seems to be the other way round.

 

I did notice however that in the Floating window layout, the GL widgets worked fine with compositing (presumably because they have separate X Windows). Is this also the case in Vista/Win7? If so I won't spend much more time on this since DR is at least usable with compositing desktops even if not all layouts are available.

[greebo]

Are you saying DarkRadiant doesn't fully working in Linux with (compiz) desktop composition switched on? Whoops, didn't notice that before. Or is this something new introduced with Karmic?

 

In Windows 7 or Vista all the layouts are working for me, although I had a visual glitch when using the drag-selection box in combination with Aero (due to the old xorrectangle implementation based on GtkDrawable, which I recently ripped out and replaced with something else). So right now, DR is working in all layouts in Windows XP, Vista and 7 even with Aero switched on, I don't have to switch off Desktop Composition or anything.

[OrbWeaver]

Are you saying DarkRadiant doesn't fully working in Linux with (compiz) desktop composition switched on? Whoops, didn't notice that before. Or is this something new introduced with Karmic?

 

I'm using KDE, but yes, with compositing switched on the default split layout renders all gray widgets which only update for a few fractions of a second if you drag the mouse in them before going back to gray. With my GtkGLArea experiments I get exactly one widget rendered, and the others behave as with GtkGLExt (which is at least an improvement, maybe something to do with binding the current widget would fix this).

 

In Windows 7 or Vista all the layouts are working for me, although I had a visual glitch when using the drag-selection box in combination with Aero (due to the old xorrectangle implementation based on GtkDrawable, which I recently ripped out and replaced with something else). So right now, DR is working in all layouts in Windows XP, Vista and 7 even with Aero switched on, I don't have to switch off Desktop Composition or anything.

 

OK, so things are better than I thought. I'm sure I read some threads about people having to disable Aero/Compositing in order to get DR to work, but perhaps this is no longer a problem except on Linux.

[greebo]

OK, so things are better than I thought. I'm sure I read some threads about people having to disable Aero/Compositing in order to get DR to work, but perhaps this is no longer a problem except on Linux.

Could still be possible, this is just my system where it's working fine. I'm using an nvidia 9700M GT, other drivers may still not play nicely along with GtkGL - some even got sluggish framerates, but that is nothing DarkRadiant can easily fix.