20,741
edits
Canvas Threading: Difference between revisions
Jump to navigation
Jump to search
m
→Problem: https://forum.flightgear.org/viewtopic.php?f=71&t=36540&p=354901&hilit=#p354901
No edit summary |
m (→Problem: https://forum.flightgear.org/viewtopic.php?f=71&t=36540&p=354901&hilit=#p354901) |
||
| Line 56: | Line 56: | ||
== Problem == | == Problem == | ||
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. | |||
It would be a problem to fix up existing Canvas-code (think NavDisplay, PFDs, EICAS etc), but with a few minor tweaks, we could come up with a dedicated Canvas mode where scripts updating a canvas property tree, are running out of the main loop. This would mean that they could not access any of the mainloop-APIs, but apart from that, it's actually a no-brainer, i.e. a straigthforward thing to do. | |||
Out of the box, OSG comes with support for creating and updating textures asynchronously, we just aren't using this currently - for obvious reasons, coding such a Canvas texture, would be a different thing. But the hooks required to make this happen, are fairly straigthforward. | |||
We have more and more aircraft that feature comparatively complex avionics, implemented on top of the [[Canvas]] stack via [[Nasal]]. | We have more and more aircraft that feature comparatively complex avionics, implemented on top of the [[Canvas]] stack via [[Nasal]]. | ||
Depending on the number of simulated displays/avionics, there is a fair share of property I/O going on, including a fair amount of redundant I/O, because many avionics/display instances share certain I/O requirements (think access to <code>/position</code>, <code>/orientation</code> etc.) | Depending on the number of simulated displays/avionics, there is a fair share of property I/O going on, including a fair amount of redundant I/O, because many avionics/display instances share certain I/O requirements (think access to <code>/position</code>, <code>/orientation</code> etc.) | ||