There are numerous underlying differences between Monterey and previous versions. Probably due to the ongoing convergence with iOS.
You have no control over which system users will run in the future. Given the acceptance rates of macOS users, I would not bet on many users remaining with an older version for the sake of running my apps.
The path is clear: the only control you have over the issue is to adapt your app to Monterey. No offense, but over 250 controls on a window is probably not good UI design. Besides, some controls probably take more time to draw than others.
Time to refactor your window, probably breaking it into several.
You did not share the kind of controls you are using, but sometimes changing that can be a great way to go around. For instance, replacing separate canvases by a unique one and drawing pseudo controls into it allowed me recently to considerably speed up an app.
So I assume they are seeing this issue on Monterey also? Did they try it on Big Sur or earlier? That is what needs to be determined - what in Monterey is causing the issue. Only then can you/they attempt a workaround.
Xojo feedback said that āYou didnāt specify, but it looks like WindowDollarValue is the window that is causing problems? I clicked on it and the IDE did appear to hang for a while, but after 2-3 minutes this window did open.ā Given that they are probably using a faster machine, and that so far I have not felt it worthwhile sitting around long enough to get an accurate timing, thatās consistent.
So what I am seeing, for this window and only this window in the IDE, is: about three SECONDS under Big Sur, maybe ten MINUTES in Monterey, and Xojo is seeing 2-3 MINUTES.
Iām asking Xojo feedback to try it with Big Sur. If they see seconds under Big Sur and minutes under Monterey perhaps they will judge that thereās something more here than an idiot user stuffing too many controls into a window.
I can cut large number of controls out of the offending window WITHOUT any obvious improvement in opening time. I have a āfeelingā it has something to do with control sets.
Iād be glad to send the project to anyone interested in helping me out.
Of course Iām going to refactor the window using containers because at this point Iām stuck on anything else to do. I donāt want to get too defensive but why yes I do know how to troubleshoot, it is a slow process when something as simple as ācut a group of controls from the window and paste them into a containerā involve a 5-10 minute delay every time! It takes a day to do as much experimentation as Iād expect to do in fifteen minutes. This is a personal toolāin fact I hardly need to build the app at all, I usually just run it from within the IDE. I never even noticed that the Mac Lite version doesnāt support text export-import, because I never wanted to use it before. Iāve been using Xojo for roughly TWENTY YEARS and I donāt remember when that capability was cut from the affordable version. No, Iām not going to defend putting that much stuff in one window, but there IS a ābugā and this should NOT be happening.
I think Iāve narrowed it down to Slider controls that have large PageStep (1000) and MaximumSize values (20000). It appears that the drawing of those on Monterey is much slower than before. Dropping them down to more reasonable values (10 and 2000) gets speeds back to what they were before.
I can live with a restriction of page step 10 and maximum size 2000. For my purposes, the problem is solved. And I solemnly promise everyone that Iāll refactor the window using Collections, but in my defense that was not the source of the problem.
I havenāt used the slider much, but in the case of a progressbar, conventional wisdom is to set the max at the actual width of the bar and calculate a percent of completion (which yields the number of pixels drawn) and only update the progressbar when the value changes. Would that apply to a slider, but in reverse?
Daniel created a case (it is private), which I have kept open. Although this is a macOS bug (I also saw it mentioned on the GitHub page for OpenCV), it might be worth limiting the range (or scale) if tick marks are enabled.
While you can, you donāt get any benefit. Being able to set a sliders value from 1 to 20000 on a control thatās 200 pixels wide means the user can only ever select 100, 200, 300 by sliding in 1 px increments. As it is, the default NSSlider uses 0.0 and 1.0 for min/max and itās up to the developer to scale the value.
Ticks are worse. Setting them to anything higher than Ā½ the width means that ticks are essentially turned off because they are so close together.
Victim here, I think some of you are blaming the victim. To begin with, Iām not quite sure I know how to determine the exact number of pixels of the length of the sliderās travel (as opposed to the length of the control). But, second, if there were some great accepted principle that the sliderās maximum value should always equal the pixel length of the sliderās travel, it would be perfectly easy to design the control so that the value was unscaledājust the raw pixel distance. Thereās no reason to provide a maximum value parameter at all. Itās only a convenience feature: the control is intentionally designed to do the scaling for you. If youāre not ever supposed to do scaling, why provide the feature?
Iām not sure what Greg O is suggesting here. I had them set at a spacing of 100 and a max value of 20,000. The sliderās about 400 pixels, so thatās 20 pixels between ticks. Thatās not at all useless.
I have it set so high because I am trying to get reasonably close to a continuous readout and set a real (not integral) value, and I want it to be high enough that the increment is determined only by pixel resolution. 20,000 is overkill, but itās also harmless. The control allows it, and it works perfectly well under Big Sur, both in the IDE and at runtime. If I were displaying 5,000 ticks I would agree that that is somewhat abusive and might expect some bad behaviorāin fact you donāt, Iāve done that accidentally! But a many-minute freeze-up in the IDE without any warning message is not good āUIā on the part of the IDE designer!
Anyway, if this is truly a macOS bugāi.e. it happens if you build the same kind of slider in Swift or Objective C or whatever is the Apple language du jourāXojoās responsibilities are pretty limited. Iām not even sure what I think they should do.
