2021R1 IDE still poking along

Just downloaded and freshly installed 21R1, opened one project (2 windows, 4 tabs each) and the code editor pokes along at 2 characters per second as I type with 100% CPU showing. Nothing that hasn’t been discussed before. Maybe 21R2…

Please take a sample and post it here. If you are on macOS, open Activity monitor, select the app, and choose “Sample Process”

Sample of Xojo_2021-03-31.txt

Thanks! I’m no expert on the inner working of the IDE, but it looks to me like it may be caught in some sort of redraw loop - object A refreshes, which causes object B to refresh, which causes A to refresh?

Do you have overlapping controls in your window? I wonder if you can delete some of the items and see if the CPU usage clears up…

Can you also take a screenshot of the desktop in the state that this happens (and blur out any sensitive info) maybe something as simple as the layout of your ide might be causing something that everyone else isn’t experiencing.

Very astute folks. The front window where the editor pokes along just has a method with its code showing, no GUI layouts of course. However the 2nd window behind it (barely visible, so no redraws should be required) does have a window layout that looks like this:

Not terribly complicated but each tab has more GUI elements so I bet they’re also refreshed even tho they’re not even visible. When I change the view of the rear window to some method editor instead, and return to the original front window, the delay is gone. So your suspicion is correct, it’s a redraw issue of a GUI layout that isn’t even frontmost, isn’t even visible because it’s totally obscured by the frontmost window showing a code editor, and is seemingly triggered after every character that is typed.

For fun, I changed the method editor in the frontmost window to a method (from a custom class, with no GUI component at all) completely unrelated to the GUI layout in the rear window, and the delay persists. So there is some terrible inefficiency that forces an entire GUI layout redraw after every character is typed even in a completely unrelated method or object.

This should be straightforward to track and fix I’d think.

Can you clarify “front” vs “rear”? Do you have 2 project windows open with different projects? One project open, with more than one IDE window? The same window in multiple tabs in a single IDE window? Also, is this Binary or Text format?

Same project, 2 windows, binary.
I opened a second project (so third window), and there is no delay in the 2nd project’s code editor, so the problem is “intra-project” evidently, not IDE-wide.

Confirmed here also in windows and macos, I’m just putting a ticket and video together for feedback, nice find.



1 Like

Thx for submitting a ticket Julian. So that explains why sometimes the code editor is just fine, other times slow, annoying but usable, and other times bordering on unusable. All depends on the complexity of the GUI layout hidden in a rear window somewhere. So maybe my wish for 21R2 might come true…

No worries. Yes, fingers crossed it can be remedied, at least we know of a workaround for the time being :slight_smile:

1 Like

The IDE can’t obviously tell whether a non-front window is totally/half/not obscured behind another window (other than calculating the window’s bounds, etc.; but it doesn’t have to). So the fact the window is behind another is irrelevant.
I’d try minimising the problematic window in the dock, as a test: the window would continue to exist but not be redrawn. Then, you’d know whether it’s truly a refresh problem (i.e. actual drawing), if it gets better, or, if not, that’d be the IDE that computes things between the two windows (and not related to the rendering part).

Perhaps you’ve spotted a big problem in the IDE…

Point taken. Maybe at least leave non-front windows completely alone as a start, and redraw them when they are brought frontmost. But the bigger issue is a GUI refresh triggered after every typed character in a code editor.
As an aside, minimizing the back window did not help, clearly the redraw code is still called even tho the back window is not visible at all. You have to change the view of the back window from a GUI view to a code editor view to relieve the delay.

Say you have two screens and two Xojo windows showing the same item (e.g. the UI of a window), one window per screen (whole windows visible on each screen, and, obviously, only one is frontmost). You move a control on the front window; you expect to see the move on the other view, even if it’s a non-front window :wink:

I can’t guess why typing anything in the code editor would produce the need to refresh the GUI view… :thinking:

Then I’d assume the issue is not about actually updating the screen, but about the code that the IDE uses to compute these changes before rendering (I’m having the assumption that a minimised window in the dock doesn’t get refreshed, except with specific calls to redraw its icon; perhaps I’m wrong here).

Yes of course, if both windows are showing a GUI view of the same item. But I can’t think of a situation where editing code would require a layout update.

Me too.