Board index FlightGear Development Canvas

Route Manager consumes a lot of Frame Rate

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Route Manager consumes a lot of Frame Rate

Postby Hyde » Tue Feb 09, 2016 10:50 pm

I find that Route Manger consumes quite a lot of frame rate when choosing far distance destination.
When I start my 777-200ER at KATL, I get frame rate 37 with my nvidia GTX760.
Then I set the VABB to destination airport and activate the Route Manager, frame rate drops to 15.
More than 50% is a bit harsh.
Can it be more economical?
Last edited by Hyde on Wed Feb 10, 2016 1:23 am, edited 1 time in total.
Hyde
 
Posts: 728
Joined: Fri Aug 12, 2011 1:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Root Manager consumes a lot of Frame Rate

Postby tikibar » Tue Feb 09, 2016 11:16 pm

A while back I narrowed this down to the way map segments around the curving earth are calculated in the canvas ND. I added a hard coded distance limiter to it that restored the calculation speed as long as no leg was longer than about 800 nm. Hooray suggested an approach that was more dynamic, but I never got around to working on it. Bottom line, it's not a graphics card issue but a calculation issue. I've seen it in both the 757 and 747-8 series using the canvas ND.

The old thread about it is here: viewtopic.php?f=71&t=24894
Boeing 747-8 (rename folder to 747-8i)
Boeing 757-200/300 (rename folder to 757-200)
Boeing 767-300/ER (rename folder to 767-300)
McDonnell Douglas MD-11 (rename folder to MD-11)
User avatar
tikibar
 
Posts: 514
Joined: Mon Mar 05, 2012 6:05 am
Location: Los Angeles
Callsign: CHT0009
OS: Ubuntu 14.04

Re: Root Manager consumes a lot of Frame Rate

Postby wkitty42 » Wed Feb 10, 2016 12:14 am

i really had to look at this a couple of times before realizing that the "route manager" is what is being discussed :?
"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: 5518
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Route Manager consumes a lot of Frame Rate

Postby Hyde » Wed Feb 10, 2016 1:54 am

My finger remembers "root cause" :oops:
Hyde
 
Posts: 728
Joined: Fri Aug 12, 2011 1:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Route Manager consumes a lot of Frame Rate

Postby Hooray » Wed Feb 10, 2016 9:57 am

Gijs provided a patch to fix the hard-coded Map dialog (and possibly the ND), it's the projection code that is causing this - as far as I know, Gijs' patches never got integrated with the Canvas system, my original suggestion was to extend the canvas projection code so that projection code can be implemented in the form of Nasal code and/or property rules.

If in doubt, please file a new feature request, linking back to this thread and any related discussions.

Issue #: http://sourceforge.net/p/flightgear/codetickets/550/
Background at: viewtopic.php?f=71&t=24201&p=229019&hilit=#p229019
Solution at: http://wiki.flightgear.org/Canvas_Devel ... rojections
Commit ID that needs to be integrated: r3f433e2c35ef533a847138e6ae10a5cb398323d7

projection handling in Canvas can be handled by dedicated C++ code automatically - Gijs has also begun adding support for new projections which provide better results/performance under certain circumstances (think flight plans crossing the poles).
[...]

according to tikibar's recent findings, we're seeing rendering/rasterization taking some time, i.e. on the Canvas side (especially related to projection handling, which Gijs is hoping to address eventually)

so maybe we can find a way to get Gijs' projection code adapted for the Canvas map

[...]
I think changing the map projection, as Gijs suggested, may be the answer to this particular problem. That is a pretty involved change. The simple change above, while not perfect and not a complete solution for all use cases, provides some relief in the meantime. The same fix could also be applied to WPT.lcontroller to do range filtering on that layer too.



Implementation details at: viewtopic.php?f=71&t=24894&p=227932&hilit=#p227932
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Route Manager consumes a lot of Frame Rate

Postby Hooray » Wed Feb 10, 2016 10:37 am

=> If you can reproduce the problem with a non-Canvas aircraft (e.g ufo) using the same route manager configuration, it's unrelated to Canvas.

=> If you can reproduce the same problem using a non-Canvas aircraft (e.g. ufo) when opening the Canvas map dialog, it's Canvas related (probably the projection handling code).
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Route Manager consumes a lot of Frame Rate

Postby Hooray » Wed Feb 10, 2016 10:50 am

Here's Gijs original commit fixing the MapWidget (hard-coded PUI widget): http://sourceforge.net/p/flightgear/fli ... b398323d7/

The Canvas projection code is well-encapsulated - usually, you only need to implement two short functions.

Here's the doxygen docs for the Canvas projection code: http://api-docs.freeflightsim.org/simge ... ction.html
This is the code currently dealing with projections: http://api-docs.freeflightsim.org/simge ... ource.html

The current projection implemented is this: https://en.wikipedia.org/wiki/Sinusoidal_projection

The class can be seen here: http://api-docs.freeflightsim.org/simge ... ction.html

The full file/code can be seen at: http://sourceforge.net/p/flightgear/sim ... ection.hxx
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Route Manager consumes a lot of Frame Rate

Postby Hooray » Wed Feb 10, 2016 11:04 am

The short-term/quick solution is porting Gijs' commit and extend the Canvas projection handling code accordingly, but in the mid-term, it would be better to provide a mechanism for registering custom projection handling code, because the number of Canvas use-cases where a hard-coded scheme would quickly show its limits, is still growing, e.g. referring to vertical projection displays (think omega95's VSD) or Thorsten's orbital map.

Thus, we really need to be sure that we provide APIs that "scale", or people will sooner or later end up implementing slow Nasal/Canvas based code, due to the lack of generic, and fast, projection handling support (to be fair, we once contemplated adding a generic projection handling library like proj4)

Image

Image
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Route Manager consumes a lot of Frame Rate

Postby Hooray » Wed Feb 10, 2016 11:55 am

Okay, currently everything is prepared for supporting multiple projections, but there is only one projection supported, and that one is hard-coded to be used in the constructor of the Map element - however the good news is, TheTom was planning to make this configurable obviously, according to the comment shown below:

http://sourceforge.net/p/flightgear/sim ... ap.cxx#l68
Code: Select all
  Map::Map( const CanvasWeakPtr& canvas,
            const SGPropertyNode_ptr& node,
            const Style& parent_style,
            ElementWeakPtr parent ):
    Group(canvas, node, parent_style, parent),
    // TODO make projection configurable
    _projection(new SansonFlamsteedProjection),
    _projection_dirty(true)
  {
    staticInit();
  }


Thus, the first step is adding our own projection code to projection.hxx, and then need to remove the projection-setting lines above and add those to the childAdded() and valueChanged() methods so that the projection can be changed at runtime, while defaulting to the old behavior if no "projection-type" property is set.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Route Manager consumes a lot of Frame Rate

Postby Hooray » Wed Feb 10, 2016 12:25 pm

Another thing that would work is coming up with a "pixel-threshold" to skip updates that are not even visible - I think TheTom mentioned that also once - currently, the Map::update() method will basically run the equivalent of a foreach loop to update each "symbol" (lat/lon), without taking into account the resolution of the map, the visibility of the element or the map's resolution.

It isn't unlikely that this would be a simple optimization to skip updates/redrawing - and when it does redraw, the projection code could be changed to use memoization/caching, i.e. a std::map<> lookup table for different std::pair<latitude, longitude> to return the matching x/y screen positions - which would mean that the cache would be populated quickly, so that redundant computations can be skipped.

Note that this would be in line with the recent PagedLOD/AI work, where the size of the AI object in screen pixels determines if it to be rendered or not.

Equally, an element having a bounding box of x*x does not necessarily need to be updated if its position only changed by 10% its visible size
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: 11317
Joined: Tue Mar 25, 2008 8:40 am


Return to Canvas

Who is online

Users browsing this forum: No registered users and 4 guests