Problem External MFD lag

DutchPlayer

Member
Joined
Jun 29, 2012
Messages
71
Reaction score
1
Points
23
Location
Goor
Hello,

When I'm doing a ascent, and I want to go Mars. I'd like to set up some MFD's. I was really excited when I saw you can open those. But when I've done that the framerate will drop dramaticly. That was the reason why I don't use it any more.

But it keeps handy when coasting to the planet, ascent, descent enz. Does anyone know how to fix this???

Dutchplayer
 
Well , I use usually 1 External MFD for launch, about 5 for proximity ops, and 3 or 4 for re-entry and landing, and I have never seen a frame rate hit, not a dramatic enough one that I notice anyway.

When I see someone go on about frame rates I feel compelled to ask, are you using the D3D9 graphics client? If not, you should. Absolutely should. You will get a nice frame rate boost, and the sim looks nicer.

I use D3D9 exclusively (well, when I am not doing some sort of testing or something, then I use D3D11).
 
Ok, I'll try the D3D9.

And thanks for your reply.

---------- Post added at 08:14 PM ---------- Previous post was at 07:51 PM ----------

Cras, thank you very much! I have no lag anymore and th e XR-2 look great!!

Again thanks!
 
I agree with Cras about D3D9Client. When I was using the inline graphics client, my performance was horrible when I put external MFD's on my second monitor. It made made Orbiter unusable. But when I switched to D3D9Client, everything was fine.
 
This is a known issue with the inline client. Use D3D9Client instead.

(The problem is actually with Windows. For some reason, the BitBlt() function, which used to extract the MFD screen, is very slow when invoked on DX7 surfaces, but much faster when invoked on DX9 surfaces.)
 
Last edited:
If the problem was with windows, I'd be inclined to suggest it is because Win7 dropped hardware support for Dx7, so the entire thing is running on software emulation, which is slow.
 
DX7 is still hardware accelerated. What isn't hardware accelerated is getting a GDI surface from DX7. DirectX/GDI interop isn't a common thing, and support for this was dropped from DX7 but continued in DX9.
 
I suspect an non-hardware accelerated GDI bitblt is the issue. I think it used to be accelerated on XP (at least if it didn't have to do a stretch (i.e. the source and destination resolutions were equal)), but no longer with Vista.

In any case, I discovered the inline client actually gives a pointer to DX7 surface with the "GetSurface" API call. From there one can do a DX7 bitblt, which is accelerated, but I digress.
 
Back
Top