On Jan 13, 2006, at 10:40 AM, Ando Sonenblick wrote:
So, a buddy discovered (using ps -acxl in Terminal) that:
1. When QT Player has no movies playing, it has a relatively
"normal" process priority of 62 or so. However, once you play one
or more movies, the process's priority jumps to 97.
This is just ps showing the highest thread priority in the process.
If you have played audio (at all, not just via QuickTime), that
thread is the CoreAudio HAL's ioProc thread for the audio device,
which is a real-time thread at priority 97. This does not mean your
app now has priority 97.
2. Similar thing happens with a browser: the browser's priority is
normal when no QT movie playing, but (via the QT plug in) if a
movie is played the browser's priority jumps to 97.
Yep, same thing.
Both of these make sense, with the latter esp. interesting since QT
is causing the priority of a process it doesnt own to change.
If QT were actually boosting the priority of the app to 97 (real-
time!) priority, it would make _no_ sense. All other apps would
screech to a halt. Your mouse might not even move (much). Playing
"arms race" with process priorities is an amazingly bad idea.
BTW, i did notice that my app, which plays back QT movies, does NOT
have its priority change when I'm playing a QT movie. Bummer,
that'd be a nice trick for bumping the performance of my app if it
did!
I assume you didn't actually play audio from your app (or perhaps you
weren't doing the exact same "ps" thing your buddy did). If you had,
you'd have seen the same thing.
Greg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
QuickTime-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quicktime-users/email@hidden
