777 freezes and FPS loss

[Hyde]

Hi,
how can i check my version ?

Don't bother, my tested version is correct.

As I mention in the other thread http://forum.flightgear.org/viewtopic.php?f=71&t=28745 canvas ND consumes a lot of frame rate when selecting far airport.
So I changed to no_canvas version of 777 and tried but frame rate decreasing still occurs on the latest.

Then I roll back to previous mentioned old 3.7 program with this no_canvas 777, it's great.
No frame rate decreasing but increase to almost max rate 60 during flight now.
There still is some issue other than canvas in the latest code.
I will find it out later.

Thanks,

[biloute974]

Hi,

I never thought this canvas can cause FPS loss.

Thanks.

[Hooray]

please don't jump to conclusions here - IF the issue is the one we were previously talking about, it's related to the projection handling code getting invoked very often for situations for which it is not suitable - which is why it's slowing down things.

However, in the other thread, Hyde mentioned already that he's seeing performance issues even in the non-Canvas 777, and that this is only getting better after downgrading the fg binary:

[sanhozay]

I have a hunch that there is a frame rate drop issue that was introduced by a commit in Flightgear or Simgear during the first half of December. I've not been able to reproduce it reliably or gather concrete proof of my hunch because I've been busy with real life but that's where I think the problem may originate.

In my case reloading scenery usually bumps the frame rate back up.

Edit: I rarely fly aircraft with canvas based displays.

Edit2: I also think it's something to do with scenery around airports/cities. Again no proof of that.

[Hooray]

it would obviously be helpful to come up with some kind of test case that can help us reproduce the problem, which would also help us with running git bisect to find the offending commit/s.

But the first thing really is coming up with a minimal test case that we can use to reproduce the problem, once we have test, we can check what's going - git bisect can even be kept running unattended as long as we have a test case that can help us automate the whole process.

[sanhozay]

Unless you know otherwise, I don't think git bisect works on this project because Flightgear commits are not linked to Simgear commits. Bisection is possible by checking out both projects by date and recompiling, but that involves bisecting dates manually.

[Hooray]

Yes, that is indeed generally true (like you say, checking out by date would/should normally work) - however, not all commits have mutual dependencies to other repositories/commits (which really is the worst case for git bisect, i.e. sg, fg and fgdata getting modified).

[wkitty42]

I have a hunch that there is a frame rate drop issue that was introduced by a commit in Flightgear or Simgear during the first half of December.

that's what i was kinda on about but i don't know when it started... it wasn't until this topic was started and i flew the route given that i was able to see it without a doubt... then i was seeing it in other craft as well and flying in other places...

[Hooray]

if possible, it would be a good idea to share your flight plan and/or fgtape so that people can try to reproduce the problem - ideally using a minimal subset of FligthGear settings, i.e. the minimal startup profile and hte ufo

[wkitty42]

as noted in the other (split) topic, there is no plan... just taking off and circling endlessly will show the problem... i'll continue my postings over there... i only wanted to respond in here about the FPS loss issue and to try to reinforce my earlier posts about it being something in the sim... i did post it to the dev list so that others with more experience could duplicate it and then they could dig in and find the offending code and get it fixed... doing that is still waaaay over my head even though i have 30+ years developing and coding projects... it is only in the last couple of years that i've ever even used a repo at all... yeah, i'm very very old school oriented

[Hyde]

As Richard mentioned in the ML, the commit that causes this issue is
flightgear, commit 154464, James Turner, Thu Dec 10 16:48:02 2015, “Remove view/tile/scenery members from globals"

Please fix this.

Thank you.

[wkitty42]

"please fix this" posted to these forums won't do any good... someone on the core has to do it... it may not be as simple as reverting it, either... especially if newer commits build on that change... i suspect that there's either a missing commit or that the continuing work in this area is not yet ready for a commit...

i won't mention that those running from the repo should expect things to be broken... especially since it is alpha/beta code and not yet ready for prime time...

[Hooray]

I haven't yet looked at the commit in question, but according to the commit message mentioned above, it seems that it /might/ be possible that the corresponding subsystems are initialized/added too often - to see if that's the case here, my suggestion would be to add SG_LOG() statements to the constructors of all subsystems affected by this commit, and then inspect the log file after starting fgfs once

Like I said, it's just one possibility - but if the code is working correctly otherwise, the most likely issue seems to be some kind of "resource leak", either in terms of memory getting leaked (i.e. lack of smart pointers/memory management techniques) and/or a combination of redundant SGSubsystem instances added too often.

[wkitty42]

I haven't yet looked at the commit in question,

http://sourceforge.net/p/flightgear/flightgear/ci/154464140528441f73da8a27d3e93ac04b72d277/

but according to the commit message mentioned above, it seems that it /might/ be possible that the corresponding subsystems are initialized/added too often

looks to me like they are being moved from (EG)

Code: Select all

globals->blah(NULL)

to

Code: Select all

subsystemManger->remove(FGblahMgr::subsystemName());

in other words, it looks like a some sort of system manager is being employed rather than just having the init'd as a global... the link above will tell you exactly what has changed in that commit... i took it directly from the flightgear-commitlogs email i received

[sanhozay]

it may not be as simple as reverting it

It's not, it doesn't revert easily. When I'd finished bisecting I tried reverting it but there has been too much water under the bridge since mid December and there were several merge conflicts.