Board index FlightGear Development Scenery

Light Weight Scenery Project?

Questions and discussion about enhancing and populating the FlightGear world.

Re: Light Weight Scenery Project?

Postby Hooray » Tue Mar 17, 2015 8:33 pm

The TG GUI "freezing" is almost certainly not related due to resource utilization - I think it is single-threaded, and it will fork/exec a bunch of programs to "compile" scenery, which is why the GUI may appear unresponsive while those programs are running. For that to change, the GUI would need to be implemented using multi-threading, which I don't think is the case currently. Depending on the OS in question, the process monitor may report false information, because it will also include forked processed.

One option we discussed a while ago was using SSH (networking) to fork those processes, which would simplify a few things - while also allowing the TG GUI to be used "remotely", e.g. for a central TG build server.

However, I haven't looked at the Qt GUI or its code in ages, so I am sure Gijs or others can better help clarify why the UI may appear unresponsive at times.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Light Weight Scenery Project?

Postby Rick Ace » Tue Mar 17, 2015 9:16 pm

Hooray wrote in Tue Mar 17, 2015 8:33 pm:
One option we discussed a while ago was using SSH (networking) to fork those processes, which would simplify a few things - while also allowing the TG GUI to be used "remotely", e.g. for a central TG build server.

Isn't that going to be complicated by security issues? Unless access is somehow restricted.

And by freezing, I mean that Windows will "fade-out" the program and put "Not Responding" next to the title.
Rick Ace
 
Posts: 1019
Joined: Fri May 14, 2010 7:02 pm
Location: New York City
Callsign: rickace
Version: 2.6.0
OS: Vista

Re: Light Weight Scenery Project?

Postby Hooray » Tue Mar 17, 2015 9:33 pm

right, that matches my earlier assumption that the UI is simple single-threaded - in other words, it can only do one thing at once - so once it starts running an external program, it can no longer update the user interface, which is why it is not responding, until the background process has finished. But a single-threaded UI not being responsive has zero to do with resource shortage - you could just as well throw a ton of horsepower at it, i.e. 500 x 32 ghz CPUs with 128 gb of RAM, and you'd still be seeing the same problem.

PS: SSH is designed around safety and security ... so no problems there - certainly not if compared to the plethora of other tools in the FG ecosystem :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Light Weight Scenery Project?

Postby wkitty42 » Tue Mar 17, 2015 11:21 pm

Rick Ace wrote in Tue Mar 17, 2015 8:17 pm:
Hooray wrote in Tue Mar 17, 2015 5:47 pm:The main accomplishment here is not the VM, but the fact that we now have pre-compiled TG binaries for debian/ubuntu, so that people don't need to build TG from source, which is also a testimony to the coding and portability work that psadro_gm and papillon81 have done over the last few years. For people wanting to run TG on multi-core platforms (like a dedicated server), using separate processes seem to work pretty well - which would probably also be the main mechanism for providing a web-frontend. So personally, I am not convinced that too much threading should be added, given how people want to reduce the setup overhead and make things much better accessible (e.g. through Gijs' QT GUI and/or the web GUI shown above).

Seeing that compiling TG is one of the hardest things to do for mainstream users such as myself, precompiled binaries are a life saver. Does the build server have the pre-compiled binaries for Debian? I'll try that out.

i've gotta be missing something... i've only been using fgfs since 3.4.0... since i found the download_and_compile.sh script, i've been beein compiling my own from the git repos... i have never seen a problem indicated in the compile logs when compiling terragear or terrageargui... in both instances, the basic build command is simply "make terragear" and "make terrageargui"... in both cases, the first time build does execute a cmake command structure...

i'm running on kubuntu 14.04... download_and_compile.sh is a GoodThing<tm> ;)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9148
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: Light Weight Scenery Project?

Postby psadro_gm » Thu Mar 19, 2015 12:16 pm

We've tried making it easier over the past couple of years to build terragear. Most terragear dependencies now are available through distribution packages. This wasn't always the case - there were a few really old, unmaintained dependencies had to be built manually - GPC and mat11 libraries come to mind. We've modified terragear to use CGAL and, if a package was unavailable, copied the source into terragear itself ( with authors permission - like the clipper library )

Pete
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 751
Joined: Thu Aug 25, 2011 3:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Light Weight Scenery Project?

Postby Hooray » Thu Mar 19, 2015 1:56 pm

for things like the TerraGear GUI to remain responsive without adding threading to the UI, one would need to use a wrapper executable that handles forking the corresponding processes and which provides status updates asynchronously (e.g. using popen in an asynchronous/polling fashion) - otherwise, the GUI will simply be stuck while running external tools via fork/exec.
In contrast, a web-based front-end like F-JJTH's work (or even Torsten's mongoose infrastructure) would need some way to schedule background jobs, which would normally be handled via cron jobs, i.e. processes being forked by a scheduler and writing output to a log file.
Back when TG was still using poco, one could have simply used the Poco::Process class to do this sort of thing in a multi-platform fashion: http://pocoproject.org/docs/Poco.Process.html

So I guess some kind high level wrapper specifically designed for UI front-end use-cases might be useful at some point, i.e. so that front-ends like the Terragear GUI and/or the web GUI would only ever deal directly with a single executable, which would internally fork/exec all the other binaries, while providing asynchronous updates - either via pipes or networking. This would allow people to come up with responsive UIs without having to be experienced in multi-threaded coding, while only dealing with a single binary.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Light Weight Scenery Project?

Postby wlbragg » Fri Mar 20, 2015 7:23 am

And by freezing, I mean that Windows will "fade-out" the program and put "Not Responding" next to the title.

I'm sure you figured this out by now but just in case your still unclear about it. This is normal and it is working correctly as in the way it was designed.

Also about the spikes, I've noticed a bunch of bad data in the SRTM data that is default grabbed by the GUI. I have since started using other sources for the elevation data. The USGS has some edited void_filled that is working well for me, but it needs to be converted from tiff (I think is what it is on the USGS site). There is a thread on this forum showing how it is done. If you get to a point where you need this information I can help you find it or send you instruction I have locally.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Light Weight Scenery Project?

Postby Rick Ace » Sat Apr 18, 2015 1:22 pm

Good Morning everyone. :D
I've been reading about TG and TG GUI as much as possible to catch up. This is why I couldn't respond earlier. Does anyone know if Windows TG will be returning to the build server?

@Hooray,

Ah, I see. :D So, Terragear continues to run while the UI still appears to "no respond".

@wkitty42,
I'm just not ready to use cmake yet, but I may venture into that when I want to compile FG.

@wlbragg,

I haven't downloaded the elevation data from the GUI. In fact, I've used ViewFinderPanaroma for elevation data. Thank you for offering your advice. :D That's very nice of you.

I'm sort of stuck on getting random spikes, despite trying it over and over.
Rick Ace
 
Posts: 1019
Joined: Fri May 14, 2010 7:02 pm
Location: New York City
Callsign: rickace
Version: 2.6.0
OS: Vista

Previous

Return to Scenery

Who is online

Users browsing this forum: No registered users and 11 guests