I had to add the kInitializeQTMLEnableDoubleBufferedSurface to the initialization of QT on Windows to make the full-screen HUD render correctly. It doesn't seem to affect non-full-screen performance, but I'm not sure if that will be true in all cases.
Setting the flag *shouldn't* do anything to non-fullscreen playback because it causes QuickTime to automatically use double-buffering for screen updates , and we never allow QuickTime to draw to the screen when doing inline playback.
Having said that, we should definitely test the performance to make sure.
What would you say is a definitive performance test? I've tried a couple of videos and can't see any difference visually or in CPU load. But I may not be trying very challenging videos.
Eric and I discussed this and did some experimentation. Looks like there is a small amount of performance loss. It's hard to tell but it could be as high as 30% on a movie that was not taxing the CPU much. Once I land the FS video patch I will try it on a less capable machine.
But we also decided that there's really no way around this. You can reinitialize QT once you've called InitializeQTML and this flag has to be set or the FS HUD flickers wildly.
But first I need to do more testing...
This can be closed, we no longer initialize QTML with kInitializeQTMLEnableDoubleBufferedSurface.