Board index FlightGear Development Canvas

extra500 lessons learnt ...

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.

extra500 lessons learnt ...

Postby Hooray » Fri Feb 21, 2014 7:17 pm

The extra500 has one of the nicest glass cockpits we have these days, but there are some things we can learn from it, regarding the way people tend to use Nasal and Canvas, some of the mistakes were also made in our early airport-selection dialog. Also, there's been quite a bit of speculation in the extra500 that performance issues are mostly due to Canvas and Nasal, without realizing that Canvas/Nasal can obviously be mis-used like any other tool/technology, for example:

  • people are obviously unaware of how often a canvas/element/group is updated, but that would be good to know for troubleshoot/profiling purposes - e.g. they're currently updating some stuff at frame rate, despite being "static" - we've made the same mistake a few times. So it would seem like a good idea expose this info via the property tree, maybe by adding some /status properties ?
  • people also seem to be unaware of the amount of RAM required to set up a canvas - in the case of the extra500, there are two fairly massive canvases created - the osg::Image/osg::texture sizes should probably be also exposed
  • making the preferred internal image format configurable would seem like a good idea in such excessive cases, at least for Canvas::Image - but probably even for the parent Canvas itself: http://lists.openscenegraph.org/piperma ... 65456.html
  • for static raster images, it may help to expose a flag that tells OSG to unref an image afterwards: http://lists.openscenegraph.org/piperma ... 65412.html
  • having an optional flag that calls ->setPixelBufferObject() on CanvasImage/Canvas may also be useful to speed up certain textures (especially anything that is heavily referenced, such as "cache" textures)
  • to prevent unnecessary speculation, we may also want to extend Canvas::Element such that each update() is wrapped in between two SGTimeStamp::now() calls whose delta_t is exposed via a PropertyObject as part of each element tree


thoughts / ideas ?
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest