20,741
edits
Canvas Threading: Difference between revisions
Jump to navigation
Jump to search
→Approach
m (→Canvas Architecture: https://forum.flightgear.org/viewtopic.php?f=30&t=36614&p=357608&hilit=#p357608) |
|||
| Line 58: | Line 58: | ||
== Approach == | == Approach == | ||
threading out all of Nasal is not trivial at all - however, modifying a handful of subsystems to allow future features to run outside the main loop, would be relatively self-contained task. | |||
If you have ever done any C++ programming for FlightGear, you realize that there is a thing called the global property tree, and that there is a single global scripting interpreter. The bottleneck when it comes to Nasal and Canvas is unnecessary, because the property tree merely serves as an encapsulation mechanism, i.e. strictly speaking, we're abusing the FlightGear property tree to use listeners that are mapped to events, which in turn are mapped to lower-level OSG/OpenGL calls - which is to say, this bottleneck would not exist, if a different property tree instance were used. | |||
This, in turn, is easy to change - because during the creation of each canvas, the global property tree _root is set, which could also be a private tree instead. | |||
Quite literally, this means changing 5 lines of C++ code to use an instance-specific SGPropertyNode_ptr instead of the global one. | |||
At that point, you have a canvas that is inaccessible from the main thread (which sounds dumb, but once you think about it, that's exactly the point). | |||
So, the next step is to provide this canvas instance with a way to access its property tree, which boils down to adding a FGNasalSys instance to each Canvas - that way, each canvas texture would get its own instance of SGPropertyNode + FGNasalSys | |||
Anybody who's ever done any avionics coding will quickly realize that you still need a way to fetch properties from the main loop (think /fdm, /position, /orientation) but that's really easy to do using the existing infrastructure, you could really use any of the existing I/O protocols (think Torsten's ajax stuff), and you'd end up with Nasal/Canvas running outside the main loop. | |||
The final step is obviously making the updated texture available to the main loop, but other than that, it's much easier to fix up the current infrastructure than fixing up all the legacy code | |||
telling the canvas system to use another property tree (SGPropertyNode instance) is really straightforward - but at that point, it's no longer accessible to the rest of the sim. | |||
You can easily try it for yourself, and just add a "text" element to that private canvas. | You can easily try it for yourself, and just add a "text" element to that private canvas. | ||
The interesting part is making that show up again (i.e. via placements). | The interesting part is making that show up again (i.e. via placements). | ||