0

My app starts and the window shows (all controls are physically there) in an inactive-like state (controls grayed out and inactive to keys/mouse). It takes three to five seconds for the window to become active? Same pattern occurs when I switch back to this app from another.

EDIT

I have added logging in various Window, Delegate & Controller methods to determine where precisely the slowdown is occurring and all of these run before the slowdown:

1. 2015-02-08 15:22:16.032 Grid[40199:5354843] ScrollGridViewContainer.awakeFromNib start
2. 2015-02-08 15:22:17.244 Grid[40199:5354843] ScrollGridViewContainer.awakeFromNib end
3. 2015-02-08 15:22:17.247 Grid[40199:5354843] contentViewController.viewDidLoad started
4. 2015-02-08 15:22:17.247 Grid[40199:5354843] contentViewController.viewDidLoad ended
5. 2015-02-08 15:22:17.262 Grid[40199:5354843] WindowController.windowDidLoad start
6. 2015-02-08 15:22:17.263 Grid[40199:5354843] WindowController.windowDidLoad end
7. 2015-02-08 15:22:17.303 Grid[40199:5354843] Window.makeKeyAndOrderFront start
8. 2015-02-08 15:22:17.316 Grid[40199:5354843] windowDidUpdate
9. 2015-02-08 15:22:17.975 Grid[40199:5354843] Window.makeFirstResponder start
10. 2015-02-08 15:22:17.975 Grid[40199:5354843] GridCell: 1, 1 .becomeFirstResponder
11. 2015-02-08 15:22:17.975 Grid[40199:5354843] self.nextResponder
12. 2015-02-08 15:22:17.976 Grid[40199:5354843] firstResponder is: 1, 1
13. 2015-02-08 15:22:17.976 Grid[40199:5354843] Window.makeFirstResponder end
14. 2015-02-08 15:22:20.692 Grid[40199:5354843] Window.makeKeyAndOrderFront end
15. 2015-02-08 15:22:20.742 Grid[40199:5354843] windowDidUpdate
16. 2015-02-08 15:22:20.772 Grid[40199:5354843] applicationDidFinishLaunching
17. 2015-02-08 15:22:20.773 Grid[40199:5354843] windowDidUpdate
18. 2015-02-08 15:22:21.216 Grid[40199:5354843] windowDidBecomeMain
19. 2015-02-08 15:22:21.238 Grid[40199:5354843] windowDidBecomeKey
20. 2015-02-08 15:22:21.322 Grid[40199:5354843] windowDidUpdate
21. 2015-02-08 15:22:25.117 Grid[40199:5354843] windowDidUpdate

On log item 14 it shows the window in an inactive state. (This is as it is exiting the Window.makeKeyAndOrderFront method after calling super)

It is only at log item 21 above that the window of my app actually became active (I moved the mouse over the window at that point to trigger a "windowDidUpdate").

My next problem to solve will be what is happening between 13 and 14 but was just trying to figure out one thing at a time...unless they're related.

UPDATE

[RE Comment by Ken Thomases below on what the console log says is happening between 13 and 14]

2015/02/08 5:30:40,963 PM WindowServer[114]: disable_update_timeout: UI updates were forcibly disabled by application "Grid" for over 1.00 seconds. Server has re-enabled them.

2015/02/08 5:30:43,568 PM WindowServer[114]: common_reenable_update: UI updates were finally reenabled by application "Grid" after 3.61 seconds (server forcibly re-enabled them after 1.00 seconds)

The occurrence of the above is linked to the size of the grid of NSTextField objects I am trying to display. Below a certain grid size it doesn't occur.

Sam
  • 2,745
  • 3
  • 20
  • 42
  • Well, then obviously something happens inside your startup. But without seeing that it's hard to tell what will slow it down. Try a few prints in your applicationDidFinishLaunching. – qwerty_so Feb 08 '15 at 10:04
  • @ThomasKilian I have added some extra info from basic println logging I have done. Not quite sure what else to do. – Sam Feb 08 '15 at 12:50
  • Well, you could add the time stamps to see where it takes time. So we see just that it reached the print. – qwerty_so Feb 08 '15 at 13:00
  • @ThomasKilian amended println to NSLog statements and changed the question. – Sam Feb 08 '15 at 13:28
  • What happens between log entries 13 and 14 in those 3 seconds? – qwerty_so Feb 08 '15 at 14:09
  • @ThomasKilian `super.makeKeyAndOrderFront(sender)` is almost surely what it is busy with. Not sure how to deep dive further behind that in an effective way. At step 13 the window has not appeared on the screen and it looks like at (or just after) 14 it appears on screen. I should add that I have a large number of `NSTextField` views in a grid formation (48x48) with constraints between themselves. – Sam Feb 08 '15 at 14:39
  • @ThomasKilian I have just run tests and can confirm that the slowdown is proportional to the size of the grid. My question is: if it has loaded the objects into memory already, what is the framework doing at those points (such that I can go and address them). – Sam Feb 08 '15 at 14:45
  • 1
    That would explain it. This are more than 2k textfields. You should change your design to use less fields. Imagine that the OS has to do quite a lot to init a single text field (see from where it inherits and look at the large amount of attributes). Nobody will ever use a grid with 2k textfields in a meaningful way. – qwerty_so Feb 08 '15 at 14:46
  • 1
    Is anything written to the system console log at the time of the delay? This would be stuff logged by the Window Server process, so it would not necessarily show up in the output from your app process. I.e. it would not be in Xcode's console output display. – Ken Thomases Feb 08 '15 at 15:15
  • @ThomasKilian I'm trying to create a spreadsheet grid (which needs millions of cells) and I've broken the problem up into only showing small sub-grids that will likely fill the screen at one time + allow for responsive scrolling. I don't really have the option of fewer text fields! – Sam Feb 08 '15 at 15:29
  • @KenThomases I have update the question with your find/catch! I don't know what it is but it doesn't sound good. – Sam Feb 08 '15 at 15:35
  • 1
    I cant help, but you need to re-think your solution. When I open Excel or the like I see at best 30*10 cells which is almost a tenth of your grid. – qwerty_so Feb 08 '15 at 15:41
  • @ThomasKilian thanks for your help thus far - genuinely appreciate it. – Sam Feb 08 '15 at 15:43
  • @KenThomases it appears that these errors only occur above a certain grid size threshold. Unfortunately, I need to have a large grid for my application! It also feels as if this relates to the usage of views versus cells in Cocoa BUT Apple are deprecating the use of Cells so it feels "wrong" to go that route. – Sam Feb 08 '15 at 16:07
  • I have seen what I believe to be bugs in Cocoa regarding UI updates being disabled, although in your case with thousands of text fields it may be legitimate. Did any of the log messages include a backtrace from your app? Have you tried using a view-based table view for the grid? That will manage only instantiating views for cells that are shown. The other way to go would be to have your grid be one view that doesn't use subviews nor `NSCell`s for the cells. It would just draw the text in the visible cells and manage a field editor for editing any given one at a time. – Ken Thomases Feb 08 '15 at 16:24
  • @KenThomases none of the log messages had a backtrace. Is NSTableView really worth considering for a proper spreadsheet (16k columns x 1m rows)? (1) Will it handle such a large grid? (2) It doesn't seem to treat rows and columns symmetrically - it's database style. I specially have "rolled my own" because I didn't think it would handle - though my grid isn't working out so well yet. – Sam Feb 08 '15 at 20:20
  • I'm not sure if it will work well for that. That's why I asked if you had tried. ;) – Ken Thomases Feb 08 '15 at 20:51
  • @KenThomases I just tried a plain 1m row by 1000 column tableView with nothing in it. Memory usage is running between 1GB and 3GB for the app. Scrolling is periodically unresponsive. I guess that's a no then... – Sam Feb 08 '15 at 21:02
  • @KenThomases I have hived off the NSView vs NSCell discussion into a separate self-contained question: http://stackoverflow.com/questions/27190183/nscell-vs-nsview-when-many-controls-are-needed – Sam Feb 09 '15 at 07:59
  • @KenThomases further trial-and-error shows that during both delays the app is busy in the nested subViews drawRect method. This accords with my finding that the smaller I make the basic grid the less the performance impact. – Sam Feb 09 '15 at 12:42

0 Answers0