[solved] wxSmith is awfully slow

[tigerbeard]

I was using wxSmith to extend a quite complex dialog with >100 control items. One day I notices that suddenly the *.wxs Tab with the Dialog layout because awfully slow. So slow that i was almost unusable. One click took min 5sec, somtimes it would re-create the dialog 2-3 times before event allowing a selection of an item. This also happened when I only changed parameters on the tree.

The workaround I found was to switch to another tab with some source code. The gui tree with the widget properties was still visible and I could normally work there.

Now I found the cause of the problem and wanted to just document it here, in case anyone has the same problem .

The cause was the graphics drivers. I am working on Linux with nvidia drivers. Somehow my graphics driver got corrupted and the system fell back to the "nouveau" driver which is basically a software emulation for all grahics accelerations. So it seems that the wxSmith dialog display is using OpenGL for rendering. I was using wxSmith for some years but did not know I am looking to a graphics windows all that time :-).
My guess is that its using the fixed-pipeline apporach wich is known to be not very performant on modern GPUS and thus even worse on software emulation.

After switching back to an nvidia driver, I note that very large dialogs are still lagging a bit and refreshs are clearly visible, but its really very usable again.

[Miguel Gimenez]

wxSmith uses whatever driver is configured in wxWidgets, what you see are real wxWidgets components.

The main problem with speed is that all the dialog code and the GUI is regenerated every time you change something. For dialogs with few widgets this is not noticeable, but for 30+ it is.

[tigerbeard]

So you say its not using OpenGL? 
Then I have no explanation why the speed change was so drastic.

But according to what you say, I should not have seen a massive improvement when hiding the wxs tab. That did not remove the rebuild of code, just the rebuild of the dialog window. An the difference was not milliseconds, it was really drastic.

[Miguel Gimenez]

So you say its not using OpenGL?

I said that it uses whatever driver wxWidgets use, see the docs of wxWidgets. setup.h on GTK has this by default:

Code

#define wxUSE_GLCANVAS       1
#define wxUSE_GLCANVAS_EGL   0

[tigerbeard]

#define wxUSE_GLCANVAS       1

Are you sure? Maybe I am wrong, but I think this flag only says wx should include the OpenGL capability into the library. Without that there is no OpenGL available at all. But imho this does not say the rendering of its widgets uses openGL. I am just thinking about the effort it takes to setup wxGLCanvas for user rendering and wonder if that could be happening behind the scenes for an odinary wxDialog. 

[Miguel Gimenez]

Here you have the full settings with comments.

Code

// Setting wxUSE_GLCANVAS to 1 enables OpenGL support. You need to have OpenGL
// headers and libraries to be able to compile the library with wxUSE_GLCANVAS
// set to 1 and, under Windows, also to add opengl32.lib and glu32.lib to the
// list of libraries used to link your application when linking to wxWidgets
// statically (although this is done implicitly for Microsoft Visual C++ users).
//
// Default is 1.
//
// Recommended setting: 1 if you intend to use OpenGL, can be safely set to 0
// otherwise.
#define wxUSE_GLCANVAS       1

// Setting wxUSE_GLCANVAS_EGL to 1 enables OpenGL EGL backend. This will be
// automatically enabled if EGL support is detected.  EGL support is only
// available under Unix platforms.
//
// Default is 0.
//
#define wxUSE_GLCANVAS_EGL   0

[tigerbeard]

Here you have the full settings with comments.
...

OK..., what part do you think refers to controls rendering?

[Miguel Gimenez]

From wxwidgets docs:

Usually wxWidgets uses the underlying low level GUI system to draw all the controls - this is what we mean when we say that it is a "native" framework. However not all controls exist under all (or even any) platforms and in this case wxWidgets provides a default, generic, implementation of them written in wxWidgets itself.

For more details refer to wxWidgets documentation, this is OT here.

[tigerbeard]

From wxwidgets docs:

Usually wxWidgets uses the underlying low level GUI system to draw all the controls - this is what we mean when we say that it is a "native" framework. However not all controls exist under all (or even any) platforms and in this case wxWidgets provides a default, generic, implementation of them written in wxWidgets itself.

For more details refer to wxWidgets documentation, this is OT here.

Right, sorry did not want to get OT. The OpenGL confused me a bit.

I know that wxWigets in Linux mostly uses gtk native controls,  Unfortunately I might add, because I ran into that when trying to match the screen density of the class browser in Linux to its Windows sibling. I utterly failed exactly because it was not rendered by wxWidgets, but just uses a native gkt2/3 control. Which incidently is lacking a working parameter to get rid of all this useless space around the single tree items. At least vertically. I fought a while with gtk theme parameters and finally gave in. But this is OT as well... :-)