Bug: oapiSetMainInfoVisibilityMode - Orbiter-Forum

fred18 · 07-20-2017, 09:56 AM

Hi, I want to highlight a small bug I encountered:

oapiSetMainInfoVisibilityMode and oapiSetMainMenuVisibilityMode

do not work correctly if they are set to 1 and then to 0 again in a matter of few steps (3 for my case).

In the space network plugin I'm developing the user will have the chance of taking a screenshot and send it around. For taking a screenshot my routine gets the main info visibility mode and the main menu visibility mode, store them, set the visibility modes to 1 in order to hide them for the picture, and after 3 frames passed it restores them.

issue is that once restored, even if they were set on show, they are not there. If I right click on the main menu area the dialog that appears correctly put them as "show" but they are not there:

it is necesseray to toggle to hide and then show again in the dialog to make them appear.

taking another screenshot (therefore making the same process again) restores them, and then the cycle repeats.

My suspect is that, since I'm not running with V-sync and with D3D9 I have a high frame rate (around 1k FPS) the 3 frames that the routine waits before restoring the visibility modes are not enough to let the client graphically render the next frame, but I don't know if it's related or not.

Thanks
Fred

**jarmonik** · 07-20-2017, 01:22 PM

I don't know if this is related to your problem. There is a delay of 3 frames in DX9 between making rendering calls and displaying the rendered frame. So, in other words the displayed image laggs 3 frames behind the actual simulation state. (No way to reduce that.)

You should wait at-least 4 frames between view state/camera changes and taking a screen shot. But something doesn't seem right since the most methods used for taking a screenshots should put the pipeline to stall (wait) because an access to render target data shouldn't be possible as long as rendering commands are queued. (need to wait to flush the queue empty). (that's the most common source of lagg) I don't know if there are exceptions in accessing front buffer data.

fred18 · 07-20-2017, 04:09 PM

Quote:

Originally Posted by jarmonik

I don't know if this is related to your problem. There is a delay of 3 frames in DX9 between making rendering calls and displaying the rendered frame. So, in other words the displayed image laggs 3 frames behind the actual simulation state. (No way to reduce that.)

You should wait at-least 4 frames between view state/camera changes and taking a screen shot. But something doesn't seem right since the most methods used for taking a screenshots should put the pipeline to stall (wait) because an access to render target data shouldn't be possible as long as rendering commands are queued. (need to wait to flush the queue empty). (that's the most common source of lagg) I don't know if there are exceptions in accessing front buffer data.

Thanks, I think that it's more relevant to the fact that I don't use vertical sync: if I let the process wait half a second between screenshot steps everything works ok, so I think that it's because it needs to render the frames in order to have the menus setup applied.

07-20-2017, 09:56 AM	#1
fred18 Addon Developer	Bug: oapiSetMainInfoVisibilityMode Hi, I want to highlight a small bug I encountered: oapiSetMainInfoVisibilityMode and oapiSetMainMenuVisibilityMode do not work correctly if they are set to 1 and then to 0 again in a matter of few steps (3 for my case). In the space network plugin I'm developing the user will have the chance of taking a screenshot and send it around. For taking a screenshot my routine gets the main info visibility mode and the main menu visibility mode, store them, set the visibility modes to 1 in order to hide them for the picture, and after 3 frames passed it restores them. issue is that once restored, even if they were set on show, they are not there. If I right click on the main menu area the dialog that appears correctly put them as "show" but they are not there: it is necesseray to toggle to hide and then show again in the dialog to make them appear. taking another screenshot (therefore making the same process again) restores them, and then the cycle repeats. My suspect is that, since I'm not running with V-sync and with D3D9 I have a high frame rate (around 1k FPS) the 3 frames that the routine waits before restoring the visibility modes are not enough to let the client graphically render the next frame, but I don't know if it's related or not. Thanks Fred

07-20-2017, 01:22 PM	#2
jarmonik Beta Tester	I don't know if this is related to your problem. There is a delay of 3 frames in DX9 between making rendering calls and displaying the rendered frame. So, in other words the displayed image laggs 3 frames behind the actual simulation state. (No way to reduce that.) You should wait at-least 4 frames between view state/camera changes and taking a screen shot. But something doesn't seem right since the most methods used for taking a screenshots should put the pipeline to stall (wait) because an access to render target data shouldn't be possible as long as rendering commands are queued. (need to wait to flush the queue empty). (that's the most common source of lagg) I don't know if there are exceptions in accessing front buffer data. Last edited by jarmonik; 07-20-2017 at 01:29 PM.

Quick Links	Need Help?
About Us Register to Participate Orbiter Website Orbiter Download Projects Recommended Addons Orbit Hangar Mods Photo Gallery Social Groups External Links	Did you forget your password? Rules & Guidelines Frequently Asked Questions Orbiter F.A.Q. Orbiter Tutorials Orbiter IRC Chat Search Forum Site Map Contact Us Mark Forums Read

07-20-2017, 04:09 PM	#3
fred18 Addon Developer	Quote: Originally Posted by jarmonik I don't know if this is related to your problem. There is a delay of 3 frames in DX9 between making rendering calls and displaying the rendered frame. So, in other words the displayed image laggs 3 frames behind the actual simulation state. (No way to reduce that.) You should wait at-least 4 frames between view state/camera changes and taking a screen shot. But something doesn't seem right since the most methods used for taking a screenshots should put the pipeline to stall (wait) because an access to render target data shouldn't be possible as long as rendering commands are queued. (need to wait to flush the queue empty). (that's the most common source of lagg) I don't know if there are exceptions in accessing front buffer data. Thanks, I think that it's more relevant to the fact that I don't use vertical sync: if I let the process wait half a second between screenshot steps everything works ok, so I think that it's because it needs to render the frames in order to have the menus setup applied.