This applies to macOS 10.13.3 beta 5 (and previous 10.13)
I have a macOS app that heavily uses custom CALayer-hosting views. When my application is freshly started everything is as expected, the UI is responsive and quick. However, after several heavy-duty "operations" involving destroying and creating of many overlapping layers as well as repainting them, my app's UI becomes almost completely unresponsive.
Simply put all UI updates like layer updates or fade-in/out animations (which is the only type of animation in use), get extremely slow. A layer fade in that normally takes a fraction of a second suddenly takes 4 seconds.
The unresponsiveness also extends to the main menu item highlighting, which becomes extremely sluggish.
I've debugged this for 3 days and can say that it isn't caused by a leak on my part (one that the Instruments would detect anyway). I can easily recreate this any time on my development machine (MacBook Pro 2016, 16GB Ram, 4k external display). The same app using the same (automated) test cycle works fine on a different MacBook Pro 2012 (8GB Ram, no external display) running macOS 10.12. My machine needs 80 test cycles to get to the state of UI freeze, the 10.12 machine can run the test indefinitely without performance impact.
Anyone else here experiencing the same problem? I'm open to the idea that this is a problem caused by me doing something that I shouldn't, but I have no clue where to look.
Regards
M
Is it possible that you're not actually removing these layers when you think that you are?
You should be able to detect something like that in Instruments - counts of CALayer objects, if the app's memory usage keeps increasing, etc... Those wouldn't always be caught by the leaks instrument depending on the specifics.
Is your app using a ton of CPU when this happens?
