1,796 bytes added
Originally, the whole Canvas idea started out as a property-driven 2D drawing system, but admittedly, what we ended up with is a system that is meanwhile tightly coupled to Nasal unfortunately. Indeed, there are some things where you definitely need to use Nasal to set up/initialize things. But under the hood, 99% still is pure property I/O, which is also why the property tree is becoming a bottleneck.
In general, Nasal is not the problem here - but the way the Canvas system is designed, and the way both, Nasal and Canvas, are integrated - it's a single-threaded setup, i.e. we are inevitably adding framerate-limited scripted code that runs at <= 60 hz to the main loop, to update rendering related state. This is a bit problematic, but it's not a real problem to fix.<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=36540&p=354901&#p354901</ref>
One option would be turning each Canvas into a canvas with its own private property tree that merely receives/dispatches events, possibly even with its own FGNasalSys instance to ensure that there is no unnecessary serialization overhead - at that point, you could update Canvas textures ("displays") asynchronously and let OSG's CompositeViewer handle the nitty gritty details of getting each sub-camera drawn/updated without running in the main loop.<ref>https://forum.flightgear.org/viewtopic.php?f=30&t=30606&p=296283&#p296283</ref>
Most Canvases could in fact have their own private property tree and a private Nasal instance directly hooked up to that tree, instead of using the current approach - as long as we're working with the assumption that all stuff only ever runs in the main loop, we are not exactly doing Nasal a huge service ....<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=31235&p=301494&#p301494</ref>
It is trivial to run Nasal in another thread, and even to thread out algorithms using Nasal.
← Older edit
Retrieved from "
About FlightGear wiki