Honestly, as far as I am aware, there really isn't any "better" or more "efficient" way to do this.
The thing is, Canvas still does not have any way of "instancing" support for OSG-level data structures - this would be the main thing that would help with reducing the rendering related workload. Aside from that, it's the update/animation logic that is typically implemented via Nasal timers/listeners that will add up, and show up over time.
Thus, the only advice/suggestion I have to make is to encapsulate the logic you are using - not necessarily in form of a classs/OOP, but even just by using a helper function in the form of a
makeBar = func (canvas, group, config, updateCallback) helper that can help you encapsulate all updating semantics.
The config parameter would then be a hash holding values for dimensions, colors to be used etc.
The main reason for doing that is to ensure that you can easily adopt more native primitives if/when they become available - for instance, the lack of a dedicated animation-handling element at the Canvas::Element level is one of the most obvious issues, because it links rendering related OSG code to Nasal space callbacks that are running within the FlightGear main loop.
And one of the most logical optimizations would be to look up suitable OSG-level data structures and expose those as Canvas::Elements that we can then reuse to implement such animations/updates without going necessarily through Nasal space - there are quite a few osg classes that could help with that, some of which we are currently re-implementing via Nasal to animate PFD/ND logic.
Looking specifically at some of the most complex Canvas-based avionics we have in FlightGear, things like Avidyne Entegra R9 will be difficult to update easily once such a dedicated element becomes available - but people can easily make that possible by using a single helper function/class that handles the update/animation semantics, and which isolates the remaining code from any internals - so that things like an animated bar can be easily delegated to OSG/C++ code as soon as the corresponding OSG classes are mapped to a dedicated Canvas element:
http://wiki.flightgear.org/Canvas_Sandb ... sAnimation