Cocoa 10.5 多线程应用程序运行缓慢
得到了一个在 10.4 中运行良好的 Cocoa 视频捕捉应用程序。 它使用 NSThread 来启动视频捕获驱动程序。 当应用程序刚启动时,视频捕获非常慢(1-2 fps)。 但调整 UI 窗口大小(或将窗口从后台移至前台)后,视频捕获速度恢复正常。 这只发生在 10.5 中。
Got a Cocoa video capture app that works fine in 10.4. It uses NSThread to start the video capture driver. When app just started, video capture is very slow ( 1-2 fps). But after resize the UI window (or bring the window from background to foreground), video capture speed is back to normal. This only happens in 10.5.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
不确定具体原因,但您应该使用 Instruments 来弄清楚发生了什么
Not sure specifically why, but you should be using Instruments to figure out what's going on
“我的应用程序很慢”的答案始终是“运行 Shark”。 有时,现在是“运行仪器”,但在大多数情况下,我发现 Shark 比 Instruments 更快地给我答案。
Shark 当然位于 /Developer/Applications 中。 如果您没有安装 CHUD,请安装,否则您就错过了。
The answer to “My app is slow” is always “Run Shark”. Occasionally, it's now “Run Instruments”, but in most cases, I find that Shark gives me an answer faster than Instruments does.
Shark is, of course, in /Developer/Applications. If you didn't install CHUD, go do that, or you're missing out.
我们有一个使用多线程视频捕获和录制的应用程序,与您所描述的类似。 我们使用 libdc1394 从 Firewire 相机进行捕获,使用 NSOpenGLView 进行显示,使用 QuickTime 进行视频编码。 相机捕获位于与 OpenGL 视频显示和 QuickTime MPEG4 编码不同的线程上。
几个月前,我们将此应用程序迁移到 Leopard,没有产生任何不良影响。 事实上,Leopard 上每秒 30 帧视频的 CPU 负载有所下降。
您是否检查过以确保正确处理所有 NSLock 等? 我们遇到了性能问题,一个线程上的锁导致另一个线程的操作停止,从而导致帧速率下降。 也许您可以考虑仅在绝对需要它们的区域放置锁,或者实现操作的无锁版本。
We have an application that uses multithreaded video capture and recording similar to what you describe. We use libdc1394 for the capture from a Firewire camera, an NSOpenGLView for display, and QuickTime for the video encoding. Capture from the camera is on a separate thread from the OpenGL video display and the QuickTime MPEG4 encoding.
Several months ago, we migrated this application across to Leopard with no ill effects. In fact, the CPU load at 30 frames per second of video decreased on Leopard.
Have you checked to make sure that you are properly dealing with all your NSLocks and the like? We've run into performance problems where a lock on one thread was halting operation on another, and consequently dropping our framerates. Maybe you could look at putting locks only around areas that absolutely need them or by implementing lockless versions of your operations.