20,741
edits
Canvas development: Difference between revisions
Jump to navigation
Jump to search
m
→Challenge: Multithreading: https://forum.flightgear.org/viewtopic.php?f=71&t=36540&p=354901&#p354901
m (→Challenge: Multithreading: https://forum.flightgear.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=canvas+private+property+tree+nasal) |
m (→Challenge: Multithreading: https://forum.flightgear.org/viewtopic.php?f=71&t=36540&p=354901&#p354901) |
||
| Line 2,833: | Line 2,833: | ||
}} | }} | ||
}} | }} | ||
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. | It is trivial to run Nasal in another thread, and even to thread out algorithms using Nasal. | ||