Mac Catalyst Getting Unacceptable Window Resizing Performance on macOS Tahoe With Liquid Glass Design

Question

Created 3w

Replies 1

Boosts 0

Participants 1

When I run my Mac Catalyst app I'm getting unacceptable performance when resizing the window. Window resizing is very unresponsive/laggy.

Configuration:

The root view controller is a UISplitViewController (three pane split using UISplitViewControllerStyleTripleColumn).
Sidebar is configured. It's using a UICollectionView sidebar style (so it looks like NSOutlineView in AppKit).
On initial launch there is no selection and the second and third view controllers in the split have empty placeholder view controllers.
At this point window resizing is fine.
Now I make a selection in the sidebar. This populates the supplementary view controller with a view controller that uses a UITableView.
Now resizing the window performance is awful. Basically this is unusable. When resizing the window a bunch what looks to be Core Animation related logs flood the console during window resize:

cannot add handler to 3 from 1 - dropping Library: QuartzCore | Subsystem: com.apple.coreanimation

Now if I go to my app's Info.plist and add: UIDesignRequiresCompatibility entry with a value of TRUE and follow the same steps described above window resizing works as expected and I do not experience performance issues. Also with UIDesignRequiresCompatibility there is no "cannot add handlers" error logs flooding the console on window resize.

Boost

Answer 1

Macho Man Randy Savage OP

3w

Because Mac Catalyst doesn't provide a great way to control width constraints of Split View controller columns (unlike the more sophisticated NSSplitView) I was proportionally computing a fraction min width/max width in -viewWillLayoutSubviews.

For example: say I want to express a max primary column width as fraction. Sidebar can only grow to 1/2 of the Split View controller width we have to use this property:

maximumPrimaryColumnWidth

But there is no maximumPrimaryColumnFractionWidth property. Hard values for max column width only makes sense IMO if your window isn't resizable (hard min may be fine though so long as the window min width is properly configured).

So to express maximumPrimaryColumnWidth as a fraction you have to compute it: (bounds.size.width/2.0).

I was doing this in -viewWillLayoutSubviews and it worked fine before Liquid Glass. But apparently doing this with the Liquid Glass design wreaks havoc. Window resizing performance is much better if I take it out of -viewWillLayoutSubviews (but still not as good as it should be TBH).

I'm aware of preferredPrimaryColumnWidthFraction, using the UISplitViewControllerAutomaticDimension results in columns that aren't really resizable in a way that makes sense for a Mac app.

So don't set properties related to min/max column width of a UISplitViewController during layout. Very bad with Liquid Glass. Why such a performance kill? I dk?

It looks like I still can't use Liquid Glass design though due to other issues. My NSToolbarItems reorder in an illogical manner when I collapse and expand Split View columns so I think I'll proceed with UIDesignRequiresCompatibility set to true for now. Plus I don't like having Split View columns you can only expand like 20-30 points.

0