okay, thanks for sharing - however, it'd be a bit surprising if this doesn't also show up when using said layer in isolation, e.g. via the map-canvas dialog ?
Under the hood, it's exercising the same code paths - so if there is any significant difference in terms of performance, that would suggest that the front-end code (the ND mess instantiating the MapStructure layer) is doing something really stupid (I should be allowed to say that, because I was involved in reworking said code to make use of the MapStructure framework, back when it had all sorts of performance issues, i.e. when it wasn't optimized at all).
Don't get me wrong, I am definitely not emotionally attacked to the ND code or the underlying MapStructure layers, but the reasoning behind that splitting/separation was indeed to be able to more easily profile/optimize and update back-end logic without having to touch tons of front-end (read: aircraft-side) code.
The long-term idea was to establish MVC concepts at the Canvas level and make it possible to create dynamically reconfigurable Canvas primitives in Nasal space, and register those as native Canvas elements, along the lines of the write-up here:
http://wiki.flightgear.org/Canvas_Devel ... FlightGearThus, what the MapStructure framework is doing, should just be considered one iteration of an ongoing process.
And if this should ever materialize beyond MapStructure.nas, that would very likely mean that the ND mess can go and be replaced with something more aligned with the MVC way of doing things (prototyping new elements in scripting space, registering those via sc::Group and providing support for customizations via element-level inheritance along the lines of Tim's effects and their property-based inheritance mechanism).