NEW INFO: Something I just noticed (because this isn’t something I’d normally do), but this is a multi-window app, with a tool palette and an image window… the image window is the one with the problem — the tool window has NO problem with resizing, it is very fast and smooth. So it’s just other windows in the app; the image editing window, the image library window.
Something in my app structure may be wrong, but I don’t know what. The symptom is that resizing my window doesn’t go smoothly — instead, it hangs for a moment, then “jerks” to the next position. Instruments says that the time is being spent in mach_msg_trap. The window isn’t doing anything – I commented out everything in an attempt to narrow down what might be causing it, and now there isn’t even a drawrect of mine going on (though the window is of course rendering its title bar and borders, etc.) So this empty window, with zero work to do, is just slow as mud.
I’ve googled like crazy, I’ve read tons of docs on runloops and windows and views, and I can’t find even a hint of what might cause this.
I’m seeing this problem under 10.5.8, xcode 3.1.3, gcc 4.0 in an 8-core machine with 8 gb of ram, lots free, and plenty of free disk space. I see the same behavior on a dual core macbook pro/2GB and a dual-core macbook/2GB, all running 10.5.8.
When all the code is in place, everything in my app works, but is compromised by the very slow update rate I’m seeing. cpu utilization isn’t very high, so there’s a lot more time available for display, it just isn’t being used.
With all my display code commented out (literally… top to bottom, no drawrect, no view code, so the app literally is doing nothing) the jerkyness is the same, but cpu utilization is almost zero. It’s like it isn’t calling the windows drawrect often enough. But I can’t find any reason why it would fail to do so.
…and by “jerky”, I mean that as I drag the little resize widget at the bottom right of the window at a moderate or even slow speed, the frame stays where it is, then “snaps” a huge distance to catch up with where the mouse has gotten to, then repeats.
Add the code back in, and it acts the same. So it’s not the drawing code. My instinct says is a structural problem — something done wrong in IB, or in how I set up the views, etc. But I can’t find anything I’m supposed to do as a matter of “this has to be done to make resize/redraw response or runloop response snappy” in any of the docs or online hints.
There’s a custom view, dragged from IB’s palette of such things, in the window. It’s set to resize automatically with the window size. And it does. But it follows the window perfectly, which is to say, jerkily. drawrect or no drawrect.
Any real cocoa experts have any ideas?
By adding an automatically generated drawing proxy to ensure the image to be drawn is never larger than the screen it is on, I’ve eliminated visible evidence of the problem.
1) The machine is fast enough to draw the screen-sized proxy quickly,
2) the end-of-resize refresh of the tool window is successful because of that, and
3) resizing (and drawing) is smooth because I’ve short-circuited the drawrect of the toolwidow when the image window is resizing.
I’m going to move on and call this dealt with by this series of workarounds, though I still think there’s clearly an underlying OS or structure issue somewhere.