Same QtOpenGL code runs as about 15 times slower when going to Carbon (vs Cocoa)

Question

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.

Answer 1

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.