by Hooray » Sun May 03, 2020 10:27 am
No matter if the selected GC mode has an impact or not, the G196 is a comparatively simple device - in fact, much simpler in terms of functionality than some of the airliners that feature multiple MFDs with EICAS/EFIS-functionality, or even the FG1000.
Which is to say that the issue is likely best resolved by troubleshooting it properly, it makes no sense for a single instance of a simple "moving map device" to have more of an impact than a other much more complex devices, using the same Nasal/Canvas based techology stack.
Most stuttering that's been so far reported in the context of Nasal/Canvas based avionics had more to do with improper use of the navdb APIs (excessive queries), or poorly-structured code, i.e. algorithms that would also show in C++ space, despite obviously with a lower impact compared to Nasal, with the most-frequent issue being improper use of timers and listeners (lack of resource management).
This is something that a number of senior core developers have repeatedly reported, and where it would make sense to consider providing dedicated APIs/frameworks to address this underlying issue, which has been long-standing.
In summary, we have some fairly complex avionics built on top of the Nasal/Canvas stack, and they're much more sophisticated than other devices, despite the latter performing often much worse.
For the time being, it's unfortunately true that it takes a fair bit of expertise and background knowledge to structure your Nasal/Canvas code in a proper fashion.
Some senior contributors have come up with helper frameworks that are sooner or later going to be made available in a generic form, e.g. look at Richard's MFD framework, Emesary, the FG10000 or the original MapStructure/ND code.