Problem Extmfd turns off vertical sync
- Thread starter ASCII
- Start date
dbeachy1
O-F Administrator
- Joined
- Jan 14, 2008
- Messages
- 9,218
- Reaction score
- 1,566
- Points
- 203
- Location
- VA
- Website
- alteaaerospace.com
- Preferred Pronouns
- he/him
Are you running Orbiter in windowed mode? Remember that vertical sync only applies to full-screen video modes, so you will always have some screen tearing in windowed mode (although it isn't always very noticable). The reason the tearing is worse with ExtMFDs open is because they can significantly increase the CPU/video load each frame (i.e., they can slow down the sim rendering all those external windows while trying to render the main window as well), increasing the "tearing" effect in the main window.
I think that when you create an extmfd object, it automatically opens in windowed mode.
I have the Orbiter graphical elements, and main application open in Full Screen on one monitor. ExtMfds open in their own "mini-windows" in my other monitor.
I have a pretty good system (Core 2 Duo 3.0hz, and 9800GX2 graphics), and I have each monitor being rendered independently by separate video cards. So I don't think that the hardware is being taxed too much.
It just seems to me that vsync loses it's effectiveness when these "mini-mfd windows" are open.
The tearing is only evident when panning the camera or rotating the camera quickly. If I close all of the extmfd windows, the tearing goes away.
I guess I'm not so concerned about the problem, this isn't a First Person Shooter.
It's just, if there is a solution, I'd like to make use of it.
I have the Orbiter graphical elements, and main application open in Full Screen on one monitor. ExtMfds open in their own "mini-windows" in my other monitor.
I have a pretty good system (Core 2 Duo 3.0hz, and 9800GX2 graphics), and I have each monitor being rendered independently by separate video cards. So I don't think that the hardware is being taxed too much.
It just seems to me that vsync loses it's effectiveness when these "mini-mfd windows" are open.
The tearing is only evident when panning the camera or rotating the camera quickly. If I close all of the extmfd windows, the tearing goes away.
I guess I'm not so concerned about the problem, this isn't a First Person Shooter.
It's just, if there is a solution, I'd like to make use of it.
martins
Orbiter Founder
Do you see this problem only with ExtMFD, or with other open dialog boxes as well?
Some background information: orbiter normally uses hardware page flipping when in fullscreen mode to flip between primary and secondary render surfaces. Hardware flipping conforms to whatever setting you chose for vsync.
However, DX7 doesn't natively support dialog boxes or other GDI elements. In order to make dialog boxes appear in fullscreen mode, a (documented) hack needs to be applied:
* The primary render surface is "flipped" to the frame buffer GDI writes to.
* A clipper object is assigned to mask out the area occupied by the dialog box
* Instead of hardware flipping, the contents of the rendered scene are blitted manually from the secondary to the primary frame buffer, using the clipper to preserve the dialog box underneath.
The last step doesn't care about the vsync setting, so as soon as a dialog box is open, vsync is effectively disabled. I don't think there is a way to avoid this (at least with the current graphics client - it may be that later DX versions support GDI better). Note that this is also the reason why some people report a sudden increase in frame rate when opening a dialog box.
Some background information: orbiter normally uses hardware page flipping when in fullscreen mode to flip between primary and secondary render surfaces. Hardware flipping conforms to whatever setting you chose for vsync.
However, DX7 doesn't natively support dialog boxes or other GDI elements. In order to make dialog boxes appear in fullscreen mode, a (documented) hack needs to be applied:
* The primary render surface is "flipped" to the frame buffer GDI writes to.
* A clipper object is assigned to mask out the area occupied by the dialog box
* Instead of hardware flipping, the contents of the rendered scene are blitted manually from the secondary to the primary frame buffer, using the clipper to preserve the dialog box underneath.
The last step doesn't care about the vsync setting, so as soon as a dialog box is open, vsync is effectively disabled. I don't think there is a way to avoid this (at least with the current graphics client - it may be that later DX versions support GDI better). Note that this is also the reason why some people report a sudden increase in frame rate when opening a dialog box.
That sounds like exactly what I am seeing.
I have experimented with using the native graphics card settings to force vsync on all applications, but that had no effect. I'll do a little more experimentation, but if the issue is linked to limitations within DX7 I doubt that it can be avoided.
Thank you for the speedy answer.
I have experimented with using the native graphics card settings to force vsync on all applications, but that had no effect. I'll do a little more experimentation, but if the issue is linked to limitations within DX7 I doubt that it can be avoided.
Thank you for the speedy answer.
Similar threads
