Right Click menu`s

[stk2008]

Hi all I am using latest 64bit KSP version.

Now I have tested this with a modded install and unmodded and it does this on both.

 

OK so your on the runway and you right click the cockpit to bring up the menu this menu will decrease FPS.

 

Now open 3 more of these windows by right clicking other craft parts and watch the FPS get even lower.

 

I have noticed on some parts modded and unmodded that some have a lot of optoins so the window can be rather large.

If this is true the FPS hit can be very high.

Is this a known issue? can it be fixed whats causing this :(.

 

Thanks in advance

EDIT

 

Forgot to add that when this happens the TIMER also flickers from yellow to green so some thing within these menus is causing some issue?.

Edited March 1, 2017 by stk2008

[diomedea]

Ok, if you like, do this test. Have KSP in a window, so you can tab in and out of it. Have all your Part Action Windows (PAW, as the right-click menu with parts is called by the devs) open, and a way to see the FPS (like the performance tab on the debug Window, Mod-F12). As you noticed, the FPS drops (the more so the more controls on PAWs displayed, like blue buttons and sliders).

Now tab out of KSP (Mod-Alt), and magically the FPS goes back to the maximum. Tab back in, the FPS drops again.

What happened? KSP keeps updating values shown on the GUI, but doesn't accept any commands until its window gains focus back. The reason for all that FPS drop is with the polling cycle with each one of those controls on PAWs, at each frame the program checks if the user is interacting, that is only performed within an active window. Unity has a quite complex way to detect a mouse action with any of the elements drawn on the GUI (since Unity 4.6, older calls to GUI elements still work but often give undesired results) so each check to perform causes a drop in FPS. Should say KSP stretches Unity to the limits, the engine isn't really designed to have so many controls on the GUI at once.

So, indeed this is a known issue, but can't be solved unless Unity changes to a more performant interaction model and KSP code is then changed to use that model (have no clue if this will ever happen).

[stk2008]

Thats awesome that it is a known issue at least :).

 

Thanks for the very fast reply appriciate that.

Lets prey and hope UNITY do some thing as this would be awesome to have fixed.

Has any one actually contacted UNITY and said about any improvments or link them to this thread?.

 

Thanks

[diomedea]

16 minutes ago, stk2008 said:

Has any one actually contacted UNITY and said about any improvments or link them to this thread?.

Don't want to show one specific link, as I have yet to find one where Unity officially took position on the issue (may exist, didn't find one yet myself). But Unity forum has a lot threads about such issues (e.g., https://forum.unity3d.com/search/7109274/?q=Mouse+polling&t=post&o=date ).

[stk2008]

Thanks again for replying well I suppose all we can do is wait?.

 

[stk2008]

Just forgot to mention this but

 

We all know the right click menus eat FPS which SUCKSSSS.

But why does it cause physics lag?.

 

I mean when I have a right click menu open some times the clock at top left flashes like bloody crazy.

Realy sucks that this is an issue as KSP relys on these menus alot :(.

 

So to sum it up we know these menus cause FPS drop but is it normal to cause such a physics lag with some of these menus?

 

[Shadowmage]

On 3/16/2017 at 7:11 AM, stk2008 said:

So to sum it up we know these menus cause FPS drop but is it normal to cause such a physics lag with some of these menus?

Yes.  Even though the game was partially multi-threaded with the change to Unity 5.x+, the majority is still single threaded -- especially the synchronization between physics and rendering.  Physics has to -stop- processing when the rendering thread is doing its thing, and as the UI stuff all lives on the render/UI thread, this causes a longer-than-optimal pause of the physics during each rendered frame.

-Some- multhreading models can do simultaneous rendering and physics, where the physics is working on the -next- frame while rendering is processing the '-current- frame, but engines setup such as those are rare'ish and have significant overhead as a large portion of the game state needs to be copied between threads every frame/physics update (at the very least object positions, velocities, and rotations).  I do not believe that Unity is one of those engines, and still uses standard thread synchronization (blocking) techniques between render and physics threads.
 

[stk2008]

Wow that was an in depth explonation :).

Sounds like its not easely fixed then :(.

Thanks for replying though and at least its not just my game/computer