No this is not the usual "my FSX performance is crapola" post, rather a query about some of the things that I have read in this forum about the FSX engine and why features like high water quality and bloom cause such a performance penalty. As I read it, these two features cause such a performance hit because they require the frame to be rendered a second time before they are put up for display. I was wondering why they need to be rendered in exactly the same frame, because as I see it the second render could be potentially run one frame behind on a second CPU core then merged back onto the current frame for display. Sure the output from these secondary functions would be one frame behind, but if this served to noticably reduce the frame rate hit of such functions and therefore kept FPS at a higher level, then a water reflection or bloom effect occuring one frame later than it was actually originally concieved would be barely noticable. Maybe even the same could go for AI traffic placement.Am I off on a different planet here, or does what I suggest remotely make sense?Gary

Gary, check your PM (2)

PM right back at ya Tom.While I'm here - bump. Anyone?Gary

This would cause noticable artifacts, and the wonderful reflections of the plane in the water would no longer be so wonderful for instance. Really everthing has to be run at the same time and right location or else the sim isnt right. So you cant really save here.And you cant just run the 2nd render on another core even if you could run parts of the sim at a lower frequency.DX9 does not allow multi-threaded Draw calls. All Draw calls must be issued from 1 thread, and that has to be the thread that created the HWND that is used to create the D3DDevice. The app can be multithreaded by using a flag at device create time ( which costs perf ) but the Draw invocations cannot be threaded. What this means is threading is limited to resource loading and math sorts of things with DX9.DX10 does fix this. Yet another thing it does better than DX9. Like better instancing, better low-batch Draw performance, lower API call invocation overhead, fewer user-kernel switches due to more of the driver being in user-mode, etc.We still need to use DX10 to maximum advantage in the FSX DX10 update, but if we do there is the potential for a major efficiency gain in the FSX engine due to the benefits of DX10.

> We still need to use DX10 to maximum advantage in the FSX DX10 update, but if we do there is the > potential for a major efficiency gain in the FSX engine due to the benefits of DX10. Sounds promising, maybe there is a light at the end of tunnel..

Thanks for taking the time to respond Phil. I thought it sounded too good to be true, but just had this incling that maybe this was just one of those "can't see the wood for the trees" issues in that the focus on current frame processing may have precluded an opportunity in a delayed flame. I'll never doubt you guys again! ;-)DX10 does indeed sound promising, even if it will take a double upgrade for most of us (Vista + DX10 video card) to realise the improvement. It never hurts to have an excuse to upgrade!Gary