MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Real_Flight_Simulator",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "14944": {
                "pageid": 14944,
                "ns": 0,
                "title": "Reaching for the stars",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "{{Stub}}\n\n{{Template:Spaceflight}}\n\n== Background ==\n{{FGCquote\n|1= Can we make a New planet in FG, call it FlightGearium, and start a simulation colony on it?\n|2= {{cite web\n  | url    = http://forum.flightgear.org/viewtopic.php?p=273619#p273619\n  | title  = <nowiki>Now that we have a new planet...</nowiki>\n  | author = <nowiki>MIG29pilot</nowiki>\n  | date   = Jan 21st, 2016\n  | added   = Jan 21st, 2016\n  | script_version = 0.25\n  }}\n}}\n\nThorsten's approach for implementing the EarthView addon is sufficiently generic to also implement other celestial bodies like this - scenery itself is a different matter though, but the TerraGear tool chain will process pretty much any elevation data you throw at it and try to turn it into scenery (DEM for Mars being freely available)<ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=250154#p250154 \n  |title  =  <nowiki> Re:  </nowiki> \n  |author =  <nowiki> Hooray </nowiki> \n  |date   =  Jul 7th, 2015 \n  |added  =  Jul 7th, 2015 \n  |script_version = 0.40 \n  }}</ref>\n\n\n{{FGCquote\n|1= We do pretty well within the Earth atmosphere, and appear to be able to do orbital flight around Earth very nicely, too. Mars and the Moon will be future projects - it shouldn't take too much work to do that. Red Canyon Software has already made a Mars airplane simulator using JSBSim some years ago.\n|2= {{cite web\n  | url    = http://forum.flightgear.org/viewtopic.php?p=132302#p132302\n  | title  = <nowiki>Re: Vostok-1</nowiki>\n  | author = <nowiki>jonsberndt</nowiki>\n  | date   = Aug 6th, 2011\n  | added   = Aug 6th, 2011\n  | script_version = 0.23\n  }}\n}}\n\n{{FGCquote\n|1= I'm not sure about Moon or Mars - but I am fairly certain we have all we need to render a hires Earth model below a spacecraft in a low Earth orbit.\n|2= {{cite web\n  | url    = http://forum.flightgear.org/viewtopic.php?p=125083#p125083\n  | title  = <nowiki>Re: New Flight Gear Terrain Engine</nowiki>\n  | author = <nowiki>Thorsten</nowiki>\n  | date   = May 22nd, 2011\n  | added   = May 22nd, 2011\n  | script_version = 0.23\n  }}\n}}\n\n{{FGCquote\n|1= rendering stuff in space is really easy the Celestia way - we can add as many textured spheres as we like. Planetary positions are tabulated, we can simply use these tables to look where to put them at any given time. I suppose even using our default engine to define moon landing sites is not a substantial issue, I am fairly sure once we can get into a Moon orbit that people can be persuaded to allow to re-center the default terrain and to use Moon textured landclasses.\nAs far as I have been told, Mathias is working on a more sophisticated low orbit rendering engine. Let's focus on getting stuff into Earth orbits, see if we can't do any docking maneuvers there, get an ISS 'static' (?) carrier (?) model into orbit and iron out all the glitches, and then see how to go to Moon.\n|2= {{cite web\n  | url    = http://forum.flightgear.org/viewtopic.php?p=153918#p153918\n  | title  = <nowiki>Re: Earthview - an orbital terrain rendering engine [v0.1]</nowiki>\n  | author = <nowiki>Thorsten</nowiki>\n  | date   = Mar 24th, 2012\n  | added   = Mar 24th, 2012\n  | script_version = 0.23\n  }}\n}}\n\n{{FGCquote\n|1= The code I'm looking at is a few of the key parts of what needs to be adapted for landing on the moon!  The ephemeris code, the lighting code, and the osg scene set up in the FG renderer.  I was thinking of exactly what needs to be done for a moon landing (or orbit) as I was looking at all of this.\n|2= {{cite web\n  | url    = http://forum.flightgear.org/viewtopic.php?p=269042#p269042\n  | title  = <nowiki>Re: Implementing moonlight (or not)</nowiki>\n  | author = <nowiki>bugman</nowiki>\n  | date   = Dec 17th, 2015\n  | added   = Dec 17th, 2015\n  | script_version = 0.23\n  }}\n}}\n\n== Prototyping ==\n{{FGCquote\n|1= given that there is so much interest in spacefllight recently, it would be cool to work out what else may end up being useful sooner or later if exposed at the property tree level, i.e. to support earthview-like approaches, without having to re-implement/work around rendering logic that already resides elsewhere - even if that just means making things better configurable (or entirely optional using dedicated draw masks), while providing for a seamless transition between the corresponding approaches\n|2= {{cite web\n  | url    = http://forum.flightgear.org/viewtopic.php?p=269035#p269035\n  | title  = <nowiki>Re: Implementing moonlight (or not)</nowiki>\n  | author = <nowiki>Hooray</nowiki>\n  | date   = Dec 17th, 2015\n  | added   = Dec 17th, 2015\n  | script_version = 0.23\n  }}\n}}\n\n{{FGCquote\n|1= an \"architecture astronaut\" might end up wondering what would be required to support arbitrary [http://www.orbiterwiki.org/wiki/Category:Celestial_bodies celestial bodies] (think Moon, Mars) by exposing those using a property-configurable texture and corresponding parameters for an osg::Shape based array of LOD-enabled spheres  :D )\nFor instance, imagine a custom PropertyList-XML dialect for instantiating celestial bodies by specifying a position, sie, and 3D models/texture sheets for different LODs.\nAnd yes, I would be willing to help work out the SGSubsystem/C++ and OSG magic/patches to make that happen in a generic fashion.\nWe already have support for adding models procedurally via /models, we can dynamically load/create/modify textures using Canvas, and we do support effects &amp; shaders - so it would mainly seem like a matter of reviewing those features to come up with an interface so that arbitrary celestial bodies can be supported using these existing features.\n(note that this seems to be how celestial bodies in Orbiter are structured: [http://www.orbiterwiki.org/wiki/Category:Add-ons http://www.orbiterwiki.org/wiki/Category:Add-ons] )\n|2= {{cite web\n  | url    = http://forum.flightgear.org/viewtopic.php?p=269035#p269035\n  | title  = <nowiki>Re: Implementing moonlight (or not)</nowiki>\n  | author = <nowiki>Hooray</nowiki>\n  | date   = Dec 17th, 2015\n  | added   = Dec 17th, 2015\n  | script_version = 0.23\n  }}\n}}\n\n{{FGCquote\n|1= Note that regardless of recent interest in supporting this, this is a really long-standing idea (just search the archives for \"moon\" or \"mars\" to see for yourelf).\n\nIn my opinion it would be a terrific idea to review the corresponding code and see if/what and how things could be adapted to become increasingly configurable - if breakage/backward compatibility should turn out to be problematic, we could introduce a dedicated subsystem - pretty much  based on the approach/features that Thorsten is using in [[Earthview#|Earthview]]\nThe basic idea being to encapsulate a light source, and LOD nodes for different ranges/visibility and texture sheets, in conjunction with effects/shaders that are to be applied.\nThis would be in line with how many other features in FlightGear started out being hard-coded, were then moved to become property-configurable, and finally become fully instantiable/modifiable at run-time (AI traffic, models, Canvas, camera views)\n|2= {{cite web\n  | url    = http://forum.flightgear.org/viewtopic.php?p=269045#p269045\n  | title  = <nowiki>Re: Implementing moonlight (or not)</nowiki>\n  | author = <nowiki>Hooray</nowiki>\n  | date   = Dec 17th, 2015\n  | added   = Dec 17th, 2015\n  | script_version = 0.23\n  }}\n}}\n\n== Canvas ==\nthe Shuttle avionics is definitely the wrong place to learn the basics of orbital mechanics... it's all not very visual<ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=285780#p285780 \n  |title  =  <nowiki> Re: Space Shuttle </nowiki> \n  |author =  <nowiki> Thorsten </nowiki> \n  |date   =  May 19th, 2016 \n  |added  =  May 19th, 2016 \n  |script_version = 0.40 \n  }}</ref>\n\n\nIdeally you would visualize it in 3d space, with the orbits as lines projected around Earth and the ability to turn and zoom.\nOtherwise the two most useful projections are groundtrack (for inclination, node crossing and what you should see looking out of the window) and the projection orthogonal to the orbital plane (basically the plot you show).\nThere's no technical issue preventing me from doing the projections at least (Orbiter uses a series of similar generic MFDs), but my priority with the Shuttle really is to re-create the original avionics. I was more commenting on the fact that the avionics makes it hard to really know your orbital state - there's no moving map, inclination isn't displayed at all, node crossing time is on a different display than apoapsis and periapsis - the Shuttle doesn't seem to have a single summary display 'this is my orbit'. \nOf course, it doesn't also have any real capability to change orbit, so your orbit is always the one you launched into modulo small corrections.\nSo from a pedagogical POV the Shuttle is a poor vehicle to learn the basics of orbital mechanics, and the Orbiter Delta Glider with it's vastly higher Delta v reserves is much better for learning (Vostok is even less suitable, it hardly has any maneuvering capability).<ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=285896#p285896 \n  |title  =  <nowiki> Re: Space Shuttle </nowiki> \n  |author =  <nowiki> Thorsten </nowiki> \n  |date   =  May 20th, 2016 \n  |added  =  May 20th, 2016 \n  |script_version = 0.40 \n  }}</ref>\n\nWe do have experimental code that also allows Canvas to be used on conjunction with arbitrary 3D models.\nBasically, what it will do is add a  new Canvas \"element type\", called \"model\", where you can specify a filename of a 3D model, and then it will add the whole thing under a osg::PositionAttitudeTransformMatrix, so that you can freely position/scale and tranform the whole 3D model arbitrarily by accessing a few properties (that are then mapped to the osg::PAT methods to rotate, scale etc)  - several elements can be added to the same \"scene\"\n[[Howto:Extending Canvas to support rendering 3D models]]\n\n[[File:Canvasmodel2.png|250px]]\n[[File:Canvas-model-element-rotated.png|250px]]\n\nit may make sense to keep this in mind, especially given bugman's \"directional moonlight\" effort, i.e. conceptually you could even load your EarthView models/textures into the same scene, and \"animate\" it using a handful of properties (obviously, there are not the conventional FG light sources (sun) or the skydome etc)<ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=285956#p285956 \n  |title  =  <nowiki> Re: Space Shuttle </nowiki> \n  |author =  <nowiki> Hooray </nowiki> \n  |date   =  May 21st, 2016 \n  |added  =  May 21st, 2016 \n  |script_version = 0.40 \n  }}</ref>\n\n== References ==\n{{Appendix}}"
                    }
                ]
            },
            "16879": {
                "pageid": 16879,
                "ns": 0,
                "title": "Read canvas image by HTTP",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "\n{{infobox subsystem\n|image = Canvas-ND-served-via-httpd.png\n|name = Canvas/HTTP Server\n|started= 10/2016 \n|description = Serving Canvas textures via httpd \n|status = Available as of 2018.3.1 (still might cause stability problems) \n|developers =  ThomasS (since 10/2016) \n<!--\n|topic-fg= \n-->\n}}\n\n== Objective ==\n{{See also|Howto:Multi-instance Canvas use}}\n<!--\n{{WIP}}\n-->\n\n[[File:ND-Dialog-with-DisplayMode-support.png|thumb]]\n\nThere are situations, e.g., for home cockpit builders <ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=296448#p296448 \n  |title  =  <nowiki> Canvas remote drawing </nowiki> \n  |author =  <nowiki> ThomasS </nowiki> \n  |date   =  Oct 10th, 2016 \n  |added  =  Oct 10th, 2016 \n  |script_version = 0.40 \n  }}</ref>, where it is useful to display instruments like a [[PFD]], [[ND]], EICAS or any [[MFD]] externally from the FlightGear 3D main window in a separate window or on a separate monitor, computer or a mobile device <ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=214980#p214980 \n  |title  =  <nowiki> Need to Create a Standalone PFD </nowiki> \n  |author =  <nowiki> deena102 </nowiki> \n  |date   =  Jul 18th, 2014 \n  |added  =  Jul 18th, 2014 \n  |script_version = 0.40 \n  }}</ref> <ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=199428#p199428 \n  |title  =  <nowiki> Re: TQ/Panel for FG made with Kivy </nowiki> \n  |author =  <nowiki> pommesschranke </nowiki> \n  |date   =  Jan 31st, 2014 \n  |added  =  Jan 31st, 2014 \n  |script_version = 0.40 \n  }}</ref> <ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=169150#p169150 \n  |title  =  <nowiki> Re: using FGpanel to display various instruments and electri </nowiki> \n  |author =  <nowiki> someguy </nowiki> \n  |date   =  Oct 23rd, 2012 \n  |added  =  Oct 23rd, 2012 \n  |script_version = 0.40 \n  }}</ref>.\n\nMany of these avionics/graphics are created by FlightGear's 2D drawing [[Canvas]] system internally. \n\n\nIn addition there, are a number of other use-cases where being able to obtain a Canvas from fgfs using a network protocol like http may be desirable (e.g. imagine getting a tilemap based on actual scenery from FlightGear <ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=203495#p203495 \n  |title  =  <nowiki> Re: Atlas still in use ? </nowiki> \n  |author =  <nowiki> Torsten </nowiki> \n  |date   =  Mar 17th, 2014 \n  |added  =  Mar 17th, 2014 \n  |script_version = 0.40 \n  }}</ref>) <ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=192817#p192817 \n  |title  =  <nowiki> How to simulate capturing an image using a camera </nowiki> \n  |author =  <nowiki> roy111 </nowiki> \n  |date   =  Oct 29th, 2013 \n  |added  =  Oct 29th, 2013 \n  |script_version = 0.40 \n  }}</ref><ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=219105#p219105 \n  |title  =  <nowiki> FGWebPanel aka FGPanel 2.0 or: FGPanel goes html </nowiki> \n  |author =  <nowiki> Torsten </nowiki> \n  |date   =  Sep 22nd, 2014 \n  |added  =  Sep 22nd, 2014 \n  |script_version = 0.40 \n  }}</ref>.\n\n\nThis article provides a patch to FlightGear for downloading any canvas image from a running FlightGear process by HTTP by serializing it to a raster image and serving that via the built-in mongoose based httpd server <ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=213146#p213146 \n  |title  =  <nowiki> Serializing a  </nowiki> \n  |author =  <nowiki> Hooray </nowiki> \n  |date   =  Jun 22nd, 2014 \n  |added  =  Jun 22nd, 2014 \n  |script_version = 0.40 \n  }}</ref> <ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=203550#p203550 \n  |title  =  <nowiki> Re: Atlas still in use ? </nowiki> \n  |author =  <nowiki> Hooray </nowiki> \n  |date   =  Mar 18th, 2014 \n  |added  =  Mar 18th, 2014 \n  |script_version = 0.40 \n  }}</ref>.\n\nThis could be considered the groundwork needed for more sophisticated use-cases such as e.g. actually streaming a live video of a certain MFD to a browser.\n\nAn additional option for displaying canvas images on remote computer is [[FGQCanvas]], which doesn't require to patch the core FlightGear code.\n\n== Problem ==\na modern biz jet will need to be able to display certain MFDs - fgpanel is not too useful for that (unless you are primarily dealing with steam gauges) - the most useful search terms for the forum/wiki will be '''Phi''' and '''FGCanvas''' - the latter of which is a special startup mode of FlightGear itself that can render Canvas based MFDs in a separate instance.\n\nIf you don't need fancy MFDs, you could probably use fgfs standalone and/or fgpanel. Phi has the lowest barrier to entry probably for people familiar with HTML and JavaScript, i.e. you don't even need to know much about fgfs.\nThe Canvas stuff will really only be needed if you want to render things like the 747 PFD/ND or CDU in a distributed fashion, i.e. using multiple independent displays.<ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=287810#p287810 \n  |title  =  <nowiki> Re: Instruments on a second monitor </nowiki> \n  |author =  <nowiki> Hooray </nowiki> \n  |date   =  Jun 6th, 2016 \n  |added  =  Jun 6th, 2016 \n  |script_version = 0.40 \n  }}</ref>\n\nyou should be aware of glass cockpit related efforts, especially Canvas - most airliners and jets will sooner or later benefit from being ported to Canvas, e.g. to use Gijs' NavDisplay framework, or at least Philosopher's MapStructure framework for mapping purposes.\n\nThus, if this is also about the actual display itself, people should be aware of related canvas efforts, especially FGCanvas: [[FGCanvas]]\n\nThe my mid-term plan involves supporting a standalone mode for all Canvas-based glass instruments, including the ND, but also other instruments like the PFD, EICAS, CDU or EFB. This may sound like a lot of work, but it's  mainlyy a matter of introducing a a few helper classes and ensuring that people actually adopt and use those.\n\nIn the long-term, we really want to support distributed FlightGear setups like those at FSWeekend/LinuxTag, where multiple computers may be used to run a single simulator session - including properly synchronized glass instruments like the PFD/ND etc. This would also help improve the multiplayer experience, especially dual-pilot setups etc.\nRegarding a pure panel with switches, kobs and buttons, we'd prefer something like that to be aircraft-agnostic, i.e. just consist of property-mapped controls that can be individually assigned, so that this could be reused for other MFDs, not just the ND - but also the PFD or EFB.<ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=211984#p211984 \n  |title  =  <nowiki> Re: computer2cockpit </nowiki> \n  |author =  <nowiki> Hooray </nowiki> \n  |date   =  Jun 7th, 2014 \n  |added  =  Jun 7th, 2014 \n  |script_version = 0.40 \n  }}</ref>\n\nThere's the long-term plan to eventually port FGPanel back into FG and come up with some sort of \"FGCanvas\" mode, where Canvas-based displays could be run in a separate \"standalone\" mode and interface to the main/master FG instance.\n\nI don't think that the Canvas system currently builds against just OpenGL ES - but it should be possible to identify problematic use-cases and make the Canvas support OpenGL ES by setting some OSG traits accordingly - at some point, i.e. 12+ months from now\nIn general, it pays off to unify things - otherwise, there's lots of duplication and re-invention involved.\n\nTechnically, we could definitely run an OpenGL ES-based Canvas on a mobile device, we just need people interested in pursuing this and playing with it - as well as report any issues/showstoppers\nSuch an integrated solution would also make it possible to show any canvas texture (instrument, dialog/window, MFD etc) on external devices:\n\n[[File:Navigation display centered MAP mode.png|250px]]\n\n[[FGCanvas]]<ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=199081#p199081 \n  |title  =  <nowiki>  & OpenGL ES (Rasberry PI, Android etc) </nowiki> \n  |author =  <nowiki> Hooray </nowiki> \n  |date   =  Jan 28th, 2014 \n  |added  =  Jan 28th, 2014 \n  |script_version = 0.40 \n  }}</ref>\n\n\n== Implementation ==\nThis solution was created roughly by:\n*adding a DrawCallback to the canvas camera\n*attach an image to the canvas camera\n*duplicate Torstens http ScreenshotUriHandler to a CanvasImageUriHandler that subscribes to the callback in the canvas camera\n\n== Alternatives ==\nThere are possible alternative solutions for rendering canvases on a remote system, that remove the rendering load from the main flightgear process. These might be based on Nasal, Javascript, Python, etc.<ref>{{cite web\n  |url    =  https://forum.flightgear.org/viewtopic.php?p=296627#p296627 \n  |title  =  <nowiki> Re: Canvas remote drawing </nowiki> \n  |author =  <nowiki> ThomasS </nowiki> \n  |date   =  Oct 14th, 2016 \n  |added  =  Oct 14th, 2016 \n  |script_version = 0.40 \n  }}</ref>\n\nOne currently available solution is [[FGQCanvas]], created by James.\n\n== Gallery ==\n<gallery mode=\"packed\">\nCanvas-in-firefox.png|Screenshot showing a Canvas camera rendered to an image streamed to FireFox\nMap-canvas dialog streamed via httpd.png|Canvas Map dialog streamed to FireFox\nPui2canvas dialog served via httpd.png|FlightGear [[PUI]] XML dialog rendered via [[Pui2canvas]] and streamed to FireFox\nCanvas-ND-served-via-httpd.png|Screenshot showing a FlightGear [[PUI]] GUI dialog with two independent [[NavDisplay]] instances streamed to FireFox\nScreenshot-streaming.png|Screenshot showing [[Canvas]] MFDs streamed to Firefox<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=30642&p=297413#p297413</ref>\nCanvas-ND-live-streaming-via-httpd.png|Screenshot showing a single Canvas texture ([[NavDisplay]]) streamed to firefox via httpd at 2hz <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=30642&p=297716#p297716</ref>\n</gallery>\n\n== Status (1/2019) ==\nThis feature was merged into the official 2018.3.1 release. It works so far. However, there are latencies and the solution isn't efficient. Just creating the PNG image from OSG takes up to 100ms.\nFor the time being, this should still be considered a \"proof-of-concept\" that may go through more iterations of optmizations. Integrating it into 2018.3.1 makes it possible to explore a number of opportunities to optimize the whole thing for different use-cases and solicit community feedback. Special attention might be required with situations where the canvas and/or the connection are shut down, but also to support [[Reset & re-init]] without causing a race  condition.\n\n{{Note|In its current form, the streaming capability <ref>https://forum.flightgear.org/viewtopic.php?f=71&p=297716#p297716</ref> is available but might overburden the flightgear process, depending on the number of canvases displayed. Its recommended not to use the streaming feature but to refresh the canvas from the browser. If any instability of FlightGear occurs, the remote canvas feature should be disabled for checking whether it is the reason.\n }}\n\n== Optimizations ==\n* Sample rate ~1-3 hz\n* JPEG_QUALITY <= 6\n* image size ~ 512x512\n* RTSP/ffmpeg streaming\n* Turn the whole thing into a configurable placement for capturing/streaming purposes\n* [[Howto:Serializing a Canvas to SVG]] (streaming a Canvas/MFD as a SVG/XML document)\n\n== Using ==\nStart fgfs with option \"--httpd=5701\" (the port number is free, but 5701 is used by the showcase HTML script). Enter the URL\n<syntaxhighlight>\nhttp://localhost:5701/screenshot?canvasindex=4&type=png\n</syntaxhighlight>\nin your browser. The first request will add the property rendertoimage to the canvas with index 4 but return no image (this is no intended behaviour but the result of insufficient synchronization between the rendering thread and the HTTP thread). The request needs to be send again and the image of canvas 4 is returned. Its up to the user to specify a valid canvas index. An invalid canvas index or any form of invalid URL will not result in an error message but simply return no result (until it runs into some browser timeout). For the 777-200 canvas index 4 is the ND, 5 the MFD. PFD seems not to use Canvas.\n\n=== Sample Showcase CanvasView.html ===\nThe following showcase HTML snippet  CanvasView.html shows the main instruments of Soitanens 737 (and its branches) with a refresh rate of 2 per second. This will not be enough for a smooth display and might be increased by reducing the timeoutinterval down from 500ms. But keep an eye on the overall performance of your running fgfs instance. Providing the images causes a significant system load. The script contains hard-coded assumptions such as the name/index of the canvas textures to download from fgfs.\n\n\n<syntaxhighlight lang=\"html\">\n<!DOCTYPE html>\n<!-- See Flightgear wiki for information-->\n<html lang=\"en\">\n<head>\n    <meta charset=\"UTF-8\">\n    <title>Canvas View</title>\n</head>\n<body>\n<select id=\"sizebox\" onChange=\"setSize();\">\n    <option value=\"256\" selected=\"selected\">256</option>\n    <option value=\"512\">512</option>\n    <option value=\"768\">768</option>\n</select>\n<table>\n    <row>\n        <td>\n            <img id=\"CptPFD\">\n        </td>\n        <td>\n            <img id=\"CptND\">\n        </td>\n    </row>\n    <row>\n        <td>\n            <img id=\"UpperEICAS\">\n        </td>\n        <td>\n            <img id=\"CptCDU\">\n        </td>\n    </row>\n</table>\n\n<script type=\"text/javascript\">\nvar refreshinterval=500;\nvar instruments = [\"CptPFD\",\"CptND\",\"UpperEICAS\",\"CptCDU\"];\nvar canvasindex = [];\ncanvasindex[\"CptPFD\"] = 3;\ncanvasindex[\"CptND\"] = 5;\ncanvasindex[\"UpperEICAS\"] = 4;\ncanvasindex[\"CptCDU\"] = 2;\n\nfunction refreshImage(imageid) {\n    //var image = document.getElementById(imageid);\n    var image = document.querySelector(\"#\"+imageid);    \n\n    var url = \"http://localhost:5701/screenshot?type=png&canvasindex=\"+canvasindex[imageid];\n    image.src = url;\n    setSize(imageid);\n    setTimeout(function() {\n         refreshImage(imageid);\n     }, refreshinterval);\n   \n}\n\nfunction setSize(imageid){\n    var e = document.getElementById(\"sizebox\");\n    var size = e.options[e.selectedIndex].value;\n    var image = document.querySelector(\"#\"+imageid);\n    if (image != null){\n        image.style.width=size+\"px\";\n        image.style.height=\"auto\";\n    }\n}\n\nfor (var i = 0; i < instruments.length; i++) {\n    refreshImage(instruments[i]);\n}\n//refreshImage(\"CptND\");\n//refreshImage(\"CptPFD\");\n\n\n</script>\n</body>\n</html>\n</syntaxhighlight>\n\n== Discussion ==\nThe forum thread for discussing this feature is https://forum.flightgear.org/viewtopic.php?f=71&t=30642&start=15.\n\n== Related ==\n* https://sourceforge.net/projects/remote-canvas-for-flightgear\n* {{Search|mode=forum|keywords=ffmpeg+stream}}\n* {{OSG example|example=osgmovie}}\n* http://trac.openscenegraph.org/projects/osg//wiki/Support/Tutorials/LoadingProgress\n* http://trac.openscenegraph.org/projects/osg//wiki/Support/KnowledgeBase/SerializationSupport\n* http://bensoftware.com/blog/comparison-of-streaming-formats/\n* http://www.osgart.org/index.php/NodeCallback_Scene_Setup\n\n== References ==\n{{Appendix}}\n\n[[Category:Cockpit building]]\n[[Category:Canvas]]"
                    }
                ]
            }
        }
    }
}