There are many compliments I’ve been meaning to make about the last few betas but have just been slammed lately. So I would rather my first post in awhile to be about how cool the later versions are, but that will have to wait.
To the point:
New Snow Leopard upgrade yesterday. DTpb7 now sends the CPU usage up to 25-50% of available CPU, ONLY when mouse is rolled over the list portion of any DT window. This happens even when another app is in the foreground. It also seems to vary by the contents of the window, for example, the global inbox seems to use more CPU than another window. This does not occur in the titlebar area, the ‘status’ area, the scrollbar area, but only in the list area itself. The window does not have to be focused - it can be a non-selected window which sends the CPU toward the redline.
Over here it’s 0.1%, no matter if active/focused or not. Tested icon view, split view and 3-pane view. Could you send a screenshot to cgrunenberg - at - devon-technologies.com plus a sample (created with Apple’s Activity Monitor while moving the mouse)? Thank you!
Man, I know this seems bogus, but I don’t know what else could cause it.
As mentioned, I tried to purge old prefpanes that I thought might have been suspects.
As mentioned, if this sort of behavior is not the kind of behavior that an application can exhibit, just post it up and I’ll rebuild the whole machine.
Only in certain circumstances, there is an incompatibility with an application called Zooom2, which allows window moving and resizing in different ways and without using the standard window handles. macupdate.com/info.php/id/23203/zooom
All is well, with more or less standard window behavior, in any multi-columned DTP window.
But, when eliminating all multiple columns leaving only the name column, DTP’s cpu usage shoots to the moon when Zooom is running and the mouse is present over the list-area of any DTP window which doesn’t have multiple columns. The mouse doesn’t even have to be moving to increase the cycles devoted to DTP.
Knowing all this, I am now assuming that Zooom is the app that has the ‘issue’, and even if that’s true I’m not sure that either developer is ‘responsible’ or has any culpability to insure that his app behaves ‘more politely’ in this case.
I knew that this was some kind of conflict but didn’t know that it would result in such intriguing discoveries as the number of columns in a window!?
So I have now communicated with Zooom’s developer and see if there’s any resolution.
It is truly strange, so for now I’m just adding any old space-consuming column in any window in which I might accidentally leave the pointer. The functionality is too valuable to forgo its benefits.
And as I mentioned to Christian, he has far more intriguing knowledge organizational theory endeavors than to get bogged down with something like this.
