Xojo 2018R2 - IDE Extremely Slow

Hi Gavin - yes, I’ve done that, no difference. I’m also using Xojo on three different Macs as well, all exhibit the same performance issues. 2016 MacBook Pro max specs, 2014 iMac 5K max specs, and 2012 MacBook Air max specs.

Just to clarify — you’re not seeing any lag whatsoever when clicking on controls or dragging items around in the GUI editor of the Xojo IDE? That is strange. I’m not sure what else I can try. I am working with pretty big projects, though nothing massive.

I had said earlier I was having these issues on blank brand new Xojo projects — that seems to have improved. Dragging is more responsive, though not instant as I had seen in REAL Studio. But whenever I’m working in an existing project, it slows down noticeably — especially on windows with pagepanels and tab views (which my apps use quite a bit). Dragging especially is very cumbersome.

My projects were always lightening fast when working with them in REAL Studio 2010. Never saw any noticeable lag.

No, I don’t see the lag you are talking about. I do tend to break my layout down, by using ContainerControls. How many controls would you have on a layout at a time?

I’ve never messed with ContainerControls, I may look into that. I’d say 10-20 controls on an average window, and anywhere from 50-100 on an average settings window. I only have a handful of settings windows, the rest are more basic.

Trust me, if you have a project with a lot controls (especially embedded in PageControls), selecting controls and dragging them is very clumsy and awkward. It has been the case for a long time now and in the last versions, it got even worse.
Nevertheless, it is no were near as bad as Xojo Windows and it is doable/workable. :slight_smile:

Maybe this is the difference then. My whole UI is always broken down into ContainerControls. For example, I never put individual controls onto a PagePanel, I drop a container onto each page.

Interesting. My biggest project has about 70 pages with each around 10 controls. So that’s is going to be a lot of work to put every page into a container. But will try it nevertheless. :slight_smile:

how would you read a recordset and assign the data from the record into the field if you have seperate container control for each page panel??

i understand if the different page has information from different table but what about one record with lots of information for each page panel. this apply to new record or editing existing records.

I was under the impression that ContainerControl was a pro feature, which is why I never messed with it. I only have a single platform deployment license so I don’t get all the fancy pro features.

It was…a Pro feature that is… but that was years ago…its now available to all

That’s good to know, thank you Dave. I will look into using them and see if it helps with IDE responsiveness.

Ok, Moved everything to containers which I then put into the pagepanels.
Helas, same slow and sluggish responding GUI. Even with one tab it is very slow selecting a couple of controls.

As said, I learned to live with it. :slight_smile:

Christoph this is the exact same behavior I’m seeing =\

Perry and Christoph, as an estimate, how many controls do you have on one window (including those on panels on the window etc that arent viewable at all times)?

Not exactly, but around 700 I guess. 10 controls on about 70 pagepanels.

Of course this is quite excessive. Still, it also happens with way less controls.

It is workable with macOS. The same project in Windows is unusable. Luckily I only use Windows to compile and check everything for the Windows builds.

Honestly, I’m not surprised it’s slow then.

It isn’t with older Xojo versions. :slight_smile:

Any how, don’t bother. I can live with it.

700 controls on a window simply scream “redo me”.

The IDE isn’t optimised for large numbers of controls.

Copy paste (duplicate) 50 labels and 50 text fields onto the same window

2015r1 15s (ran twice to make sure this wasn’t a fluke)
2016r3 3m19s :open_mouth:
2016r4.1 1m2s
2017r3 1m27s
2018r1 1m47s
2018r2 55s
2018r3a24 53s
VS 2.5s T_T

It looks like something serious happened between 2015 and 2016 that hasn’t been optimised fully yet. I don’t have more releases installed from that period to narrow it down but the numbers speak for themselves. Control selection speed has also altered over that period. The more controls you have on a window the longer things take, pasting or selecting.

*All my tests were done in windows.

[quote=403716:@Richard Duke]how would you read a recordset and assign the data from the record into the field if you have seperate container control for each page panel??

i understand if the different page has information from different table but what about one record with lots of information for each page panel. this apply to new record or editing existing records.[/quote]
Just like everything else, you have Load/Save methods on your Containers that you pass the information to. We do this with ActiveRecord ALL the time. And if there’s any validation that we need to for the UI the validate method is in the Container as well. So yeah, your Window load method will be a lot of:

dataobject = db.somequery
container1.Load(dataobject)
container2.Load(dataobject)
container3.Load(dataobject)

containerX.Load(dataobject)

But this has the advantage of isolating the code to the container. So if the window overall has 1000 controls but Container1 has 20 controls, debugging the Container is much easier and any exceptions related to code in that container are much easier to figure out then if your Window is dealing with all 1000 controls.

If the UI on Container1 has to change because of something on Container3 we implement an event on Container3 so the parent Window/Container can get the event and tell Container1 to do whatever changes.

I think many Xojo developers underutilize Container Controls. They are very powerful and very useful - especially with a UI that’s busy and complex. I gladly trade off needing more code to make it simpler to work with (if that makes sense).

None of this may be related, but

last year I changed an internal format from ‘memoryblocks & arrays’ to ‘XML Document’ in order to be able to serialise data more flexibly.
That massively slowed down the copy/paste aspects of my project when the object count got high, and I had to refactor it all over again to take XML out of the equation.

I can also say that copying part of a picture to another graphic using drawpicture is much slower than copying the whole picture. So any images that are held with states side by side in one png file will be slower to use.

Maybe internally, Xojo is running into something similar since 2015?