SOLVED - CodeEditorComponent as debug console; horribly slow on Windows but not Mac

General JUCE discussion
1

I’m using a CodeEditorComponent as a debug console. I have a separate window that is an AsyncUpdater holding the CodeEditorComponent, and I can log messages to it by assembling them into a StringArray, calling triggerAsyncUpdate(), at which time the StringArray messages received since last time are assembled into a chunk of text and inserted into the CodeEditorComponent.

On the Mac, the updating and scrolling of the logged messages is lightning fast, and is able to keep up even when posting a new log entry every 1 ms.

On Windows, it becomes horribly bogged down and can end up many seconds behind the actual logging events. You can disable the logging and it will take 10~20 seconds to finish printing everything that’s backed up.

Any ideas on why that might be the case?

2

So I rebuilt everything as a Release version, and the horrible slowness on Windows goes away. It’s as fast as the Mac version, and totally usable.

However, since I mainly want to use this feature in the Debug version, does anyone have any ideas why the CodeEditorComponent is so awfully slow when compiled as Debug on Windows? It would seem to be the scrolling and redrawing as you insert chunks of text that tanks it. Is there anyway to change some #defines or something to fix this for the Debug version?

Maybe one of these?

//==============================================================================
// juce_graphics flags:

#ifndef    JUCE_USE_COREIMAGE_LOADER
 //#define JUCE_USE_COREIMAGE_LOADER 1
#endif

#ifndef    JUCE_USE_DIRECTWRITE
 //#define JUCE_USE_DIRECTWRITE 1
#endif

#ifndef    JUCE_DISABLE_COREGRAPHICS_FONT_SMOOTHING
 //#define JUCE_DISABLE_COREGRAPHICS_FONT_SMOOTHING 0
#endif

//==============================================================================
// juce_gui_basics flags:

#ifndef    JUCE_ENABLE_REPAINT_DEBUGGING
 //#define JUCE_ENABLE_REPAINT_DEBUGGING 0
#endif

#ifndef    JUCE_USE_XRANDR
 //#define JUCE_USE_XRANDR 1
#endif

#ifndef    JUCE_USE_XINERAMA
 //#define JUCE_USE_XINERAMA 1
#endif

#ifndef    JUCE_USE_XSHM
 //#define JUCE_USE_XSHM 1
#endif

#ifndef    JUCE_USE_XRENDER
 //#define JUCE_USE_XRENDER 0
#endif

#ifndef    JUCE_USE_XCURSOR
 //#define JUCE_USE_XCURSOR 1
#endif

#ifndef    JUCE_WIN_PER_MONITOR_DPI_AWARE
 //#define JUCE_WIN_PER_MONITOR_DPI_AWARE 1
#endif
3

You should follow/borrow the dbg console from PluginVal if you need this. Search the forum for where to get PluginVal’s source code.

4

Thanks for the suggestion. So I downloaded it, compiled it, looked at it - and it is using the exact same model that I am already using.

It uses a CodeEditorComponent for the console display. It is assembling and posting the messages in a handleAsyncUpdate() call, same way. Mine is virtually identical. So I don’t really see any improvements here that I can grab from that…

The scrolling is soooooooooo slow on Windows, when compiled as debug…

5

SOLVED. In my Windows Debug version, I have included the Visual Leak Detector library. I had not realized that this is well-known to cause a large performance hit. When I remove it and recompile, the performance of the CodeEditorComponent is fine.

1 Like
6

What is this?

And why is JUCE_LEAK_DETECTOR(classname) not enough?

7

Visual Leak Detector is a third party VS plugin. It adds a big overhead in order to help debug the memory bugs, and it can be used on any (or most) VS C++ project.

8

Visual Leak Detector provides much more information than JUCE leak detection; can be helpful in determining where some hard-to-find leaks are.

1 Like