Resizing, closing documents and some other things are very slow on Linux

[CapsAdmin]

It can take up to 1 second to resize the IDE, close a document, switching documents, and some other things. This depends on the window size of the IDE. I have a 4k monitor but I usually keep the IDE at 1080p~

I've tested this on KDE Plasma and icewm (some really old lightweight window manager) and it's the same. It's the same on wxwidgets31x-upgrade as well. This doesn't happen in a windows 10 vm running on the same machine though.

[pkulchenko]

@CapsAdmin, I'd try couple of things: (1) is the effect the same if you close all editor tabs? (2) is the effect the same if the small/large file is opened in the editor? (3) what if you close panels one-by-one and check if the effect is the same?

I haven't noticed this, but I only run Linux in VMs on a macbook pro, so the window is not large in that case.

[CapsAdmin]

It's still very slow if I close the bottom panel, the file tree and have an empty document open.

[pkulchenko]

And what if you don't have an empty document open? Is it still slow? I'm trying to figure out if it's editor related or not...

[pkulchenko]

@CapsAdmin, I wonder if you see the same effect on wxlua samples: https://github.com/pkulchenko/wxlua/blob/origin/tags/wxLua-2.8.12.3/samples/, expecially auidemo and editor (these are standalone examples, so you can simply open them in the IDE and run). If you still see the slowness (assuming the same window size), then you can try on more simple samples (including those that come with wxwidgets, to see if the issue is with the toolkit itself). If there is no issue with the editor and auidemo samples, we can start searching for what makes the IDE slower as its design is similar to the editor sample, just with more complex logic.

[CapsAdmin]

It's a lot faster if I close the document even if it's empty. The standalone editor filled with the code of itself is also a lot faster.

[pkulchenko]

Elias, do you see high CPU utilization when the IDE is idle (which could explain slowness when dragging)? It's still a bit strange that it depends on the window size, but maybe if CPU is already busy, it just makes the effect more visible? Having said that, I still don't see what could make document switching slower. I guess I'd need to try few things running it full screen. Are you still on kubuntu 15.04?

[CapsAdmin]

during resize it's at 25% cpu (i have 4 cores)

I was wrong about document switching, that's fast. I was thinking of closing documents which seems to depend on window size. Yes I'm using kubuntu but I'm also using the neon packages.

[pkulchenko]

How about the idle CPU right before you start resizing?

In terms of closing, the only thing that I think may be relevant is the size of the project index you may have (as as far as I remember, you may have a large project), which may be re-saved when a tab is closed (I'll need to double check). Even if that's the case, it doesn't seem to be relevant to resizing. Maybe there is a combination of several overlapping factors?

[pkulchenko]

@CapsAdmin, I tried in my Kubuntu 15.04 VM with the application taking the entire screen on MacBook Pro, but I don't see any slowness with any operations ;(. I also see the horizontal ghost line when resizing the bottom panel. I suspect this may be related to your local configuration. Can you try without plugins, with an empty user.lua (both system and user), and with emptied session configuration ($HOME/.ZeroBraneStudio) as it includes your index cache (you may move the file/folder if you don't want to re-scan your projects)? I think this will be a good check whether it's related to your local configuration/environment or not.

[CapsAdmin]

I was testing this without any packages. It's still slow even if I remove the .ZeroBraneStudio index file. (which made it not load a project by default so everything is blank too)

If I change the resolution to 1080p this becomes less noticeable. If the IDE's size is 1080p and above resizing becomes difficult.

[pkulchenko]

@CapsAdmin, I'm still trying to figure out if this is something in the IDE or wxwidgets that is causing this, but given that the slowness is still showing up on an empty project, it may be related to wxwidgets.

There is only one event that is triggered on resizing; can you try commenting out the following handler to see if it makes any difference: https://github.com/pkulchenko/ZeroBraneStudio/blob/master/src/editor/gui.lua#L48-L55

If that doesn't help, could you try the following?

1. Open build/build-linux.sh and comment out line 166 (rm -rf "$WXWIDGETS_BASENAME").
2. Run (cd build; ./build-linux.sh wxwidgets). This should build wxwidgets libraries used in the IDE
3. cd build/wxWidgets/samples/aui; make; This should build auidemo executable.
4. Run auidemo executable to check if you observe the same slowness on it.

[CapsAdmin]

I don't have the tool-bar visible in the first place but it didn't help.

The auidemo is also slow but it feels little bit faster than zerobrane.

[pkulchenko]

@CapsAdmin, it's interesting that you didn't see any slowdown on the editor demo from wxlua samples (and yet it seems to be related to the presence of wxSTC/Scintilla component). Not sure yet what to make of this...

[CapsAdmin]

You asked me on IRC to run a small demo with 2 empty documents tabbed, it's the same. The wxwidgets demos are also slow. I've tried compiling them without any of the flags in build_linux.sh but issue remains.

Interestingly if I run the zerobrane.exe with wine resizing is not slow.

I asked #wxwidgets at freenode and I was asked to try CodeLite, which is an all purpose IDE that uses wxwidgets. This IDE does not have this problem. Maybe some flag somewhere is used?

[pkulchenko]

@CapsAdmin, thank you for checking the demos and discussing this in #wxwidgets. It's somewhat comforting that it doesn't seem to be caused by the IDE code on top of wxwidgets, but I'm interested to figure out what may be causing this. I'll check with the CodeLite author to see if he has any suggestions.

[pkulchenko]

@CapsAdmin, CodeLite is using its own notebook components; so far it seems like the slowdown may be caused by wxAuiNotebook, which is using wxAuiManager internally to size the components on the page as it's being resized. I'll poke around a bit more, but at this point I'm not sure what else can be done to troubleshot it further. Thank you for the assistance!

[pkulchenko]

@CapsAdmin, no changes in the performance on these operations in the IDE? I'm not sure what else to do about it, but also don't want to keep it hanging... Any updates/suggestions?