While it is true that a Canvas::Element is currently updated/rendered within the main loop, there's no reason why certain elements could not be run/updated in a worker thread and only synchronized at frame rate with the main process/loop - in fact this sort of thing is directly supported by OSG by using the corresponding OSG data structures and setting some traits, so far we just haven't had any need to actually do this, because Canvas stuff is usually fast enough.
Besides, you could simply use the existing Canvas::Image element for this and sub-class it - it only really deals with raster images, so you could simply compute/update the raster image asynchronously, outside the main loop and serialize things then.
In fact, having worked with the HLA and OpenRTI bindings, those could even be used to prepare the whole thing to be done in a different process, while still supporting distributed setups.
By the way, I am not at all opposed to the idea or features, but it would obviously be a good idea to come up with an approach that actually scales, and doesn't lock out certain use-cases.
PS: regarding "smart ideas" the two of us could probably have a really interesting discussion (as technical as you want it to be by the way), but please: before we use words like "smartest idea", we should probably make sure that we're all on the same page and actually understand the issue at hand sufficiently, or things are unlikely to remain/become constructive. Then again, in its current form, FlightGear is exhibiting more threading related issues than ever before, we've been seeing dozens of race conditions and segfaults related to those - so maybe adding more "threading" isn't exactly the best idea either, which is something that Curt has been suggesting for almost two decades by the way ?