20,741
edits
Canvas Draw: Difference between revisions
m
→Animation Handling
No edit summary |
|||
| Line 85: | Line 85: | ||
At some point, anything involving symbol/display animations (i.e. Nasal callbacks handling updates via timers and listeners) should ideally be wrapped using a corresponding set of helper classes, so that if/when more appropriate native helpers become available, such "animations" can be easily mapped to corresponding native code, instead of relying on hundreds of Nasal timers and listeners, which are infamous for being the most likely culprits when it comes to resource leaks. | At some point, anything involving symbol/display animations (i.e. Nasal callbacks handling updates via timers and listeners) should ideally be wrapped using a corresponding set of helper classes, so that if/when more appropriate native helpers become available, such "animations" can be easily mapped to corresponding native code, instead of relying on hundreds of Nasal timers and listeners, which are infamous for being the most likely culprits when it comes to resource leaks. | ||
The background being, from a profiling standpoint, we really need to be using more OSG-level data structures and map those to "canvas properties", to do away with things that Nasal code is currently handling, especially those doing context switches between Nasal and native code using timers and listeners. | |||
The most prominent use-case being Canvas "animations" built on top of timers and listeners - OSG has native data structures for doing this sort of thing, and we only really need to introduce new elements (or even just attributes) to make use of those, which would also mean doing away with tons of Nasal-induced overhead due to timers and listeners animating a Canvas element currently. | |||
For instance, the real issue arises once people want to interact with a Canvas MFD (think PFD, ND, FG1000) using out-of-process tools (FGQCanvas, Phi, tablet PCs, Android phones, Rasberry Pi etc), at which point all crucial internal state that merely resides in Nasal/scripting space is hugely problematic - whereas everything that is part of the Canvas/Element-specific property tree hierarchy can be trivially supported without people having to know anything about Nasal. | |||
We should have introduced dedicated elements for dealing with animations without going through Nasal space using timers and listeners long ago. In the meantime, it makes sense to make sure that all such uses are encapsulated by using a corresponding set of helper classes that can be easily updated once better APIs become available. | |||
== HUD Parser == | == HUD Parser == | ||