Hey, thanks for keeping us posted!
That sounds good to me - like I said, I wouldn't expect any kind of impressive performance using that sort of approach - however, it should actually work "well-enough" on the same machine/network, but you may still want to look into using some of OSG's more advanced threading options to make sure that the capturing part doesn't unnecessarily affect other things - normally, you could reserve some fixed amount of RAM and let OSG handle this by copying the frame.
Apart from that, my suggestion would still be to put up your code so that others can use it - as you have certainly seen, this is a recurring/popular feature request actually, so having a public git repository that contains the corresponding patches would be cool -alternatively, please consider adding your patches to the wiki (if in doubt, just add them to the corresponding Canvas related articles to which I linked a few days ago).
Technically, a more "proper" way would be wrapping your code in a so called "Canvas placement" (see the wiki section on placements) - in this case, we'd have a virtual placement, in the sense that the main window doesn't necessarily display such a placement which exposes a Canvas via the built-in httpd/mongoose.sever.
Note that this would also mean that _any_ Canvas could be streamed using your approach, just by adding a corresponding "placement" (via Nasal).
No matter what you decide, it would be cool if you could share your code so that others can take a look.
Then again, grabbing/capturing, and even streaming live imagery from OSG is a very common thing in OSG land, and frequently discussed on the OSG users list - I think there also a handful of examples on doing this "properly", so you may want to review those or even consider posting there to get additional feedback (best practices).
I think for a proof-of-concept this should actually suffice - the Nasal/JavaScript idea will involve a bit of Nasal/JavaScript metaprogramming, so you would need to be fairly familiar with both languages - but conceptually, a Canvas can be represented as a SVG (and vice versa), i.e. interrnally, SVG could be used as the representation format, and it could reference a bunch of dynamic contents by fetching resources from fgfs via httpd.
This sort of thing would be browser-based obviously, but you could benefit from Torsten's groundwork - anything fgpanel/fgcanvas-like will inevitably require OpenGL hardware and hardware acceleration - i.e. the whole fgcanvas thing was originally about running a restricted subset of fgfs with most subsystems disabled, and merely canvas related stuff running, and some networking to sync/replicate the corresponding properties via some form of IPC (networking probably, for distributed setups).
Note that this wouldn't be much about OSG/OpenGL hacking, but more about general FG hacking, i.e. about making stuff optional/better configurable to keep it disabled - thus, it's less confined work, but definitely not as involved as setting up a new OSG cam to capture/stream a screenshot.
If your main focus is implementing something generic without it being browser-based and without requiring OpenGL/OSG, you would probably want to use a format that is well-supported by the corresponding technology stacks - e.g. by treating each top-level Canvas as a virtual SVG file - we once talked about that (like years ago), but basically we could provide each Canvas::Element with a serialize() method that turns each element into a valid serialization form, such as turning Canvas/OSG text nodes into SVG nodes, Canvas::Image (raster images) into <image> etc.
That sort of work would be relatively straightforward, and it would allow for serving an animated SVG file (e.g. representing a MFD; HUD, or even GUI dialog) - any dynamic elements would obviously need to be fetched from the fgfs instance, e.g. via Torsten's mongoose work or some other form of IPC.
We would basically need to add an abstract CanvasSerializer and implement that for SVG, animations would ideally be wrapped in a helper element, at that point, even dynamic/changing elements could be serialized by using a subset of SMIL/JavaScript (which is valid SVG)
I cannot currently find the original topic, but we talked about this 2~3 years ago - the main motivation being that this would open up all sorts of possibilities, such as using Inkscape (or any other SVG) editor to fully create/animate and maintain sophisticated avionics, without having to do much/any Nasal coding.
Some of the more relevant pointers in the wiki seem to be:
http://wiki.flightgear.org/Howto:Using_ ... erator_(IG)
http://wiki.flightgear.org/Slaving_for_Dummieshttp://wiki.flightgear.org/Canvas_Devel ... torming.29http://wiki.flightgear.org/Canvas_Prope ... ave_setupshttp://wiki.flightgear.org/Canvas_Prope ... er_or_filehttp://wiki.flightgear.org/Canvas_Devel ... ializationhttp://wiki.flightgear.org/Canvas_Sandboxhttp://wiki.flightgear.org/Canvas#Using ... G_projects(Note that none of this is set in stone obviously, these are just a bunch of related ideas we've had, and a few related code snippets - but maybe this helps you form an informed opinion and determine your goals/priorities given the approaches/ideas we discussed)
Please be sure to keep us posted, and please also feel invited to update the wiki accordingly !