相同的 QtOpenGL 代码在使用 Carbon 时运行速度大约慢 15 倍（与 Cocoa 相比）
我正在使用 Qt 和 OpenGL（以及 QtOpenGL）为 Mac OSX 平台开发一个非常简单的应用程序，因此跨平台变得更容易。
应用程序接收数量可变的视频流，这些视频流必须渲染到屏幕上。这些视频流的每一帧都用作在 3D 空间中映射矩形的纹理（与视频墙非常相似）。 除了诸如接收、锁定、上传视频数据、同步线程之类的事情之外……我认为很明显这是一个非常简单的应用程序。
事实上，在 10.5 Mac 上使用基于 cocoa 的 Qt 4.7 二进制文件（默认二进制文件）时，一切都正常。 但我的代码必须在从 10.4 开始（包括到）的所有 OSX 版本上都能正常运行。所以我在 10.4 机器上尝试了代码，它在启动时就崩溃了。经过几个小时的互联网阅读后，我发现对于面向 10.4 的 Qt 应用程序，必须使用基于 Carbon Qt 的应用程序。所以我用新框架重建了整个项目。
当新生成的二进制文件运行时，除了应用程序的 fps 下降到大约 2 fps 之外，一切都运行良好！它在两台机器上的行为相同（10.5 计算机具有明显更好的功能） 我花了相当多的时间来解决这个问题，但还没有找到解决方案。有什么建议吗？
有关应用程序和我尝试过的事情的更多信息，
- 在重新编译仅使用两个基于碳的
- （256x256 纹理）视频时，代码没有被修改，以确保它不是带宽限制问题（尽管我知道它不应该，因为第一个）代码有效）
- 2个视频流从网络（本地）到达
- 当视频流到达时，发出信号并且数据将上传到OpenGL纹理（glTexSubImage2D）
- 计时器使渲染（paintGL）在大约20ms（〜50）发生fps）
- 渲染代码使用纹理（更新或未更新）来绘制矩形。
- 由于有 2 个（异步）视频流，仅当视频到达时才进行渲染将不起作用；除此之外，还有更多的东西必须在屏幕上绘制。
- 只使用基本的 OpenGL 命令（没有 PBO、FBO、VBO...）唯一有问题的可能是着色器的使用（仅从 Qt 4.7 开始可用），但其代码很简单。
- 我已经使用了 OpenGLProfiler 和 Instruments。没有观察到任何特别/奇怪的情况。
我怀疑的一些事情（结论）
- 很明显这不是硬件问题。同一台计算机的行为不同，
- 这让我感觉这是一个线程/锁定问题，但是为什么呢？
- 碳是32位。 10.5应用程序是64位。它不可能在碳中开发64位。
- 为了放弃 32 位可能的原因，我还重建了 32 位的第一个项目。它的工作原理部分相同。
- 我读过一些关于 Carbon 在上下文切换方面遇到问题（比平常更多）的内容。
- 也许OpenGL实现是多线程的，而代码不是？ （或者相反？）这可能会导致很多停顿。
- 也许碳处理事件的方式与可可不同？ （我的意思是信号/事件调度，主循环......）
好吧，这是（抱歉写了这么长）我真正的头痛。任何建议、想法..将不胜感激。
提前谢谢。
I'm developing a very simple application for the Mac OSX platform making use of Qt and OpenGL (and QtOpenGL) so crossplatform gets easier.
The application receive a variable number of video streams that have to be rendered to the screen. Each frame of these video streams is used as a texture for mapping a rectangle in 3D space (very similar to a videowall).
Apart from the things such as receiving, locking, uploading video data, synchronizing threads... i consider it is clear that it's a quite simple application.
The fact is that all behaves ok when using cocoa based Qt 4.7 binaries (the default ones) in a 10.5 Mac.
But my code has to run fine at all of the OSX versions starting from (and including to) 10.4. So i tried the code in a 10.4 machine and it crashed just when starting. After a few hours of internet reading, i discovered that for a Qt Application to be targeted at 10.4, carbon Qt based has to be used. So i rebuild the whole project with the new framework.
When the new resulting binary gets run, all works well except by the fact that application's fps fall to about 2 fps!! And it behaves the same at both machines (10.5 computer has sensibly better features)
I've spent quite time working on this but i have not reached a solution. Any suggest?
More information about the application and things i've tried
- code has not been modified when recompiling carbon based
- only two (256x256 textures) videos ar used in order to assure it's not a bandwidth limit problem (although i know it shouldn't because the first code worked)
- the 2 video streams arrive from network (local)
- when a video stream arrives, a signal is emmited and the data will be uploaded to an OpenGL texture (glTexSubImage2D)
- a timer makes render (paintGL) happen at about 20ms (~50 fps)
- the render code use the textures (updated or not) to draw the rectangles.
- rendering only when a video arrives won't work because of having 2 (asynchronous) video streams; besides more things have to be draw at screen.
- only basic OpenGL commands are used (no PBO,FBO,VBO,...) The only one problematic thing could be the use of shaders (available only from Qt 4.7), but its code is trivial.
- i've made use of OpenGLProfiler and Instruments. Nothing special/strange was observed.
Some things i suspect (conclusions)
- it's clear it's not a hardware issue. The same computer behave differently
- it gives me the sensation it's a threading/locking problem but, why?
- carbon is 32 bits. The 10.5 application was 64. It's not possibly develop 64 bits in carbon.
- for giving away the 32 bits possible cause, i also rebuild the first project for 32 bits. It worked partically the same.
- i've read something about carbon having problems (more than usual) with context switching.
- maybe OpenGL implementation is Multithread and code is not? (or the opposite?) That could cause a lot of stalls.
- maybe carbon handle events differently from cocoa's? (i mean signal/event dispatching, main loop...)
Ok, this is (sorry for the so long writing) my actual headache. Any suggestion, idea.. would be very appreciated.
Thx in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我可以问一个诊断问题吗？您能确保它不会被传递给软件渲染器吗？
我记得10.4发布时，对quartz Extreme、quartz和carbon存在一些混淆，其中一些被禁用，其中一些默认禁用硬件渲染器，这需要最终用户进行配置才能使其正常工作。我不确定这个信息是否相关，因为你说，以 10.4 为目标，问题在 10.4 和 10.5 上都出现，是吗？
即使在 10.5 Carbon 中，默认情况下也有可能不使用硬件渲染器（尽管我承认我在这里抓住了救命稻草）。我想尽管 OSX 在所有情况下都更喜欢硬件渲染器而不是软件渲染器，但考虑到您已经对其他选项进行了彻底的研究，可能值得花一点时间进行研究。
祝你好运。
May I ask a diagnostic question? Can you ensure that it's not being passed to the software renderer?
I remember that when 10.4 was released, there was some confusion about quartz extreme, quartz and carbon, with some of it disabled, and hardware renderers disabled by default on some of them, which required configuration by the end user to get it working correctly. I'm not sure whether this information is pertinent, because you say that, having targetted 10.4, the problem exhibits on both the 10.4 and the 10.5, yes?
It's possible (though admittedly I'm grasping at straws here) that even in 10.5 carbon doesn't use the hardware renderers by default. I'd like to think though that OSX prefers hardware renderers to software renderers in all scenarios, but it may be worth spending a little time looking into, given how thoroughly you're already looking into other options.
Good luck.
如果您使用 Qt，我想您的代码可以在 Windows 或 Linux 平台上运行。您是否在这些平台下尝试过您的应用程序？
这将很快揭示它是来自 Qt 还是 mac OSX 版本。
If you are using Qt, I guess your code would work on a windows or linux platform. Have you tried your application under these platforms ?
This would quickly reveal if it comes from Qt or the mac OSX version.