The same QtOpenGL code runs about 15 times slower when switching to Carbon (vs Cocoa)

Question

I am developing a very simple application for the Mac OSX platform using Qt and OpenGL (and QtOpenGL), so the cross-platform becomes simpler.
The application receives a variable number of video streams that should be displayed on the screen. Each frame of these video streams is used as a texture to display a rectangle in three-dimensional space (very similar to a video stream). Besides such things as receiving, blocking, downloading video, synchronizing streams ... I believe that this is a fairly simple application.

The fact is that everything behaves normally when using cocoa Qt 4.7-based binaries (default) on a 10.5 Mac. But my code should work fine in all versions of OSX, starting from (and including before) 10.4. So I tried the code in machine 10.4, and it crashed only at startup. After several hours of internet reading, I found that for a Qt application intended for use in 10.4, it is necessary to use carbon Qt. Therefore, I am rebuilding the entire project using a new structure.
When a new resulting binary is launched, everything works well, except for the fact that the fps application drops to about 2 frames per second! And it behaves the same on both machines (computer 10.5 has reasonably better features) I spent a lot of time on this, but I did not find a solution. Any suggestion?

Additional information about the application and what I tried

• code was not changed when recompiling based on carbon
• only two (256x256 textures) video ar are used in order to guarantee this is not a problem of bandwidth limitation (although I know that this should not, because the first code worked)
• 2 video streams come from the network (locally)
• upon receipt of the video stream, the signal will be transmitted and the data will be loaded into the OpenGL texture (glTexSubImage2D).
• the timer renders (paintGL) at about 20 ms (~ 50 frames per second)
• the rendering code uses textures (updated or not) to draw rectangles.
• rendering only when a video arrives will not work due to the presence of 2 (asynchronous) video streams; In addition, more things need to be drawn on the screen.
• only basic OpenGL commands are used (without PBO, FBO, VBO, ...). The only problem may be using shaders (available only from Qt 4.7), but its code is trivial.
• I used OpenGLProfiler and tools. Nothing special / strange was observed.

Some things I suspect (conclusions)

• this is not a hardware problem. The same computer behaves differently.
• this gives me a sense of a thread / lock problem, but why?
• Carbon - 32 bits. Appendix 10.5 was 64. It may not develop 64 bits in carbon.
• to give out a 32-bit possible reason, I also rebuild the first project to 32 bits. It worked partially the same.
• I read something about carbon having problems (more than usual) with context switching.
• Perhaps the OpenGL implementation is multi-threaded, but the code is not? (or vice versa?) This can cause many stalls.
• perhaps carbon-treated events other than cocoa? (I mean the signal / event dispatcher, the main loop ...)

Well, this (sorry for writing such a long time) is my real headache. Any suggestion, idea .. would be greatly appreciated.

thanks in advance.

Answer 1

Can I ask a diagnostic question? Can you guarantee that it will not be passed to software rendering?

I remember that when 10.4 was released, there was some confusion regarding quartz, quartz, and carbon, some of which were disabled, and hardware renderers were disabled by default for some of them, which required the end user to configure correctly. I’m not sure that this information is appropriate, because you say that by setting 10.4, the problem appears in both 10.4 and 10.5, right?

It is possible (although admittedly I grab the straw here) that even at 10.5 carbon does not use hardware renderers by default. I would like to think that OSX prefers hardware renderers for rendering software in all scenarios, but it might be worth a little time to learn, given how thoroughly you are already exploring other options.

Good luck.

Answer 2

If you use Qt, I think your code will run on a Windows or Linux platform. Have you tried your app on these platforms?

This will quickly detect if it comes from Qt or the Mac OSX version.