Board index FlightGear Development Canvas

Canvas G1000

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Re: Canvas G1000

Postby Hooray » Sun Nov 19, 2017 10:14 am

Remote Canvas / FGQCanvas & event handling
James wrote:
Stuart wrote:This is very cool, and gives me extra incentive to get further on the
G1000 project.

Are you intending to support sending events back natively so that button presses
etc. can be handled, or will that need to use some other mechanism (emessary)?

I will add native event support - that’s why I prompted Richard to add native touch event support as an animation type, and we can make the canvas handle that locally. The idea is the client side is very thin, there’s no Nasal or anything in it, it’s just a renderer and event source, similar to VNC but obviously way more efficient because only property changes are sent.

BTW this should also work for the Canvas-map, but I didn’t test that all yet - images are one of the least developed parts for now so I’m not sure how the tile management would cope but in *principle* it should all just work.



Now that Richard has started hooking up his Emesary IPC framework to the MFD framework, I would like to reiterate my suggestion to consider/discuss wrapping all MFD bindings (those triggering events/notifications) using fgcommands instead of pure Nasal blobs - the point being that sooner or later you may want to actually run multiple instances of the FG1000 - e.g. by showing several instruments in a single dialog or by opening separate dialogs with independent instances.

This kind of thing can become pretty messy once you use Nasal blobs all over the place (been there, seen it) - fgcommands are much cleaner than that, and they have the added advantage that other front-ends can just as easily access/use the FG1000 MFD without having to know anything about Nasal or Emesary - i.e. you are basically encapsulating event handling (Emesary notifications) using fgcommand (do note that if this were generally done, that adopting an IPC mechanism like Emesary would also be much simpler than reviewing/editing tons of Nasal blobs in the <bindings> section of a cockpit/UI dialog).

I am currently having the same discussion with Richard, trying to make the point why using Nasal in the bindings part of the MFD is problematic in the long term - for pretty much the same reasons that James encouraged Richard not to use Emesary for his new Touch Animation.

The point being that external front-ends like Phi, FGQCanvas, tablet PCs, mobile phones, dedicated cockpit hardware etc can trivially access properties and run fgcommands, but that they cannot as easily deal with bindings in the form of Nasal blobs - we can however deal with that problem easily by going through the fgcommand API and registering our MFD/Emesary Callbacks as dedicated MFD specific fgcommands:

Hooray wrote:an fgcommand can be just that: a conventional Nasal callback (including a method) - it's a just a property-tree enabled version of an API/IPC mechanism so that other back-ends don't need to know anything about Nasal.
I do think that James pointed out the power of this approach when you were discussing the "touch animation".

Under the hood, it's really just C++ code that gets a handle to a property tree node and returns true/false - what the Nasal addCommand() is doing is provide a mechanism to allow arbitrary Nasal code to be registered in the form of an fgcommand.

What that means is that fgcommands can invoke bindings that don't need to support nasal - this is extremely powerful when dealing with stuff that runs outside the fgfs process space - imagine Phi/mongoose, or James' FGQCanvas work, but also any other out-of-process application that may benefit from invoking Nasal code in an RPC/IPC fashion without actually supporting it.

I haven't discussed this with anyone else, only touched on it briefly on the forum and in a few wiki articles - but if in doubt, I'd suggest to check back with some of other core developers/long-term contributors to see if they can see the merits of pursuing this or not.

The takeaway really is that Emesary callbacks can be provided in the form of fgcommands - which means that your Nasal code can remain "as is" - but that all stuff using Emesary can transparently invoke Nasal code, without having to know anything about it - which kinda is the whole point of a framework like Emesary, right ?

Regarding the question you raised (passing a Nasal hash as a property) - that is what props.nas has helpers for: setValues() and .getValues() will transparently do just that.

As you can probably tell by now, I am not suggesting anything novel or complicated - but merely a shim layer to provide fgcommand-based bindings for Emesary, so that other use-cases (outside fgfs) may not need to actually know anything about Nasal or Emesary, which I think is the point of the exercise, isn't it ?

If in doubt, just take a brief look at these:
http://wiki.flightgear.org/Nasal_librar ... mand.28.29
http://wiki.flightgear.org/Howto:Add_ne ... FlightGear

This isn't to say that the Emesary framwork itself will need to be exposed that way, but merely some of its event/action handling routines - because that is typically what other front-ends and back-ends are likely to be interested in: triggering events and actions.

So, I am really having the bigger picture in mind here - i.e. a distributed fgfs setup with a handful of instances, and what they'd need in terms of infrastructure and building blocks to properly sync/replicate Canvas related MFD state (think Stuart's G1000) across multiple instances using a single IPC-enabled MFD framework.

So this is not about asking you to implement something, but rather to encourage having the discussion to see if/how we can have our cake and eat it - I don't care if you end up using fgcommands or not - it's just something that I tend to do, and recommend, for the lack of better tools; but also in the light of other folks being slightly concerned about important features being solely implemented in scripting space (think Advanced Weather), and that would surely also apply to stuff like Emesary, because people (read: core devs) who don't like Nasal, surely won't go crazy about adopting a Nasal based IPC framework for pretty much the same reasons that they don't like Nasal in the first place.

To sum up things: With the goals stated above, I do think that adding Emesary support to the MFD framework would be a good idea, but I also think that establishing a way to prototype/test MFDs using a standalone GUI dialog with skins/themes does make sense - and I would rather not see people using low-level Nasal blobs all over the place to trigger events and actions in response to someone clicking a button or cockpit hotspot, but would rather see them use a single "command layer" that has nothing to do with Nasal - which is what fgcommands are good at (despite the back-end code still residing in Nasal space possibly). The point being that FGQCanvas, dedicated hardware/tablet PCs or mobile phones can then render a working G1000 MFD without any of the front-ends having to know low-level details about niche technologies like Emesary or Nasal.

Equally, using the approach where an enumerated list of events/actions and callbacks can be traversed with some meta data to provide labels/tooltips for each action (think cockpit dial) would make it straightforward to let Phi render a G1000-style MFD, without Torsten having to tinker with Nasal/Emesary at all - that is, as long as everything goes through APIs that all other external software simply understands - namely, properties & fgcommands.

Again, please don't spend even just a single minute implementing any of this if you don't think it's a good idea - but please do consider discussing such goals with people involved in the various efforts (e.g. Stuart/FG1000 and James/FGQCanvas, Torsten/Phi).

What we have been doing in the Canvas department in the last 5+ years is hugely problematic and adding to the pile of work we have, and even more problematic due to Nasal's general status/reputation, but also the fact that this stufff (Nasal+Canvas) runs in the main loop.

A good, and properly-designed, MFD framework can be protoyped in scripting space and could be moved to native code sooner or later to address these challenges in a feasible way - but for that to succeed, we literally need to look at the use-cases we currently have and make sure that people can eat their cake and have it, which means providing an IPC mechanism that allows people disliking Nasal still using it, without them having to know anything about the underlying implementation details.



Hooray wrote:the rationale for my suggestion to encapsulate Nasal use for hooking up Emesary notifications via fgcommands are out-of-process front-ends that need to interact with the in-sim Canvas MFD:

Torsten's Phi/mongoose front-end:
http://wiki.flightgear.org/Phi
Image

Stuart's FG1000 effort:
http://wiki.flightgear.org/FG1000
Image

James' FGQCanvas:
Image

ThomasS Canvas httpd streaming support:
http://wiki.flightgear.org/Read_canvas_image_by_HTTP
Image

I think, you'll agree that Emesary could be THE IPC solution to solve the problem, but that adding/requiring Nasal support would be a little far-fetched - nevertheless, the people/end-users using these mechanisms would definitely want to be able to interact with the MFD.

And these are just a few examples - there are others to be found, e.g. where people are interfacing their cell phones/tablet to FlightGear for pretty much the same reasons, or where they'd like to interface actual cockpit hardware to FlightGear that needs to interact with the Canvas MFD.

Using an IPC mechanism like Emesary here is definitely the right solution, but requiring Nasal in the command/bindings part is probably considered controversial and not desirable from the standpoint of those opposed to Nasal.

Using the fgcommand route would also mean that other back-ends, e.g. those using Python, could still trivially interact with the same Canvas MFD bindings, without having to know anything about Nasal at all.

Again, this is not to convince you - but just to encourage you to solicit feedback and make up your own mind. For instance, just imagine for a second what it would take to render Stuart's FG1000 in Phi - all we'd need is the streaming patch we have already, and we could trivially render a Canvas remotely - the difficult part is elsewhere, i.e. making it respond to events coming from another process that are usually implemented in the form of Nasal blobs executed in the <bindings> part of the dialog/cockpit panel.

Once you begin using only fgcommands here (wrapping Emesary itself), the front-end no longer matters at all ...

(hope I am making sense, even if you should disagree on technical grounds ...)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas G1000

Postby stuart » Mon Nov 20, 2017 11:32 pm

Hi Hooray,

Richard kindly added the Emesary support so that I could use it for the FG1000 to help get the architecture right. For the moment I've got the GUI calling Emesary directly, but there's no reason why I can't change that to fgcommands in the future. I think I want to get slightly further in my work before I do that though - I want to have some confidence that I'm creating the right granularity of commands first.

I'm hoping to have a first version of the FG1000 MFD using a PUI surround and with two example pages (Navigation Map and the Traffic Map), the EIS and page navigation complete in the next week. I'm hoping that once I've got that done I'll have created enough of a framework that the rest of the MFD pages can be created relatively easily without some massive re-factoring effort.

It'll be good to get your feedback at that point - I strongly suspect there are various areas that could be handled more cleanly.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Canvas G1000

Postby Hooray » Tue Nov 21, 2017 8:43 pm

Just to be clear about it, I am not emotionally attached to the fgcommand approach or the underlying idea.

And to be perfectly honest, Richard didn't seem overly enthustiatic about the idea when I suggested to provide an Emesary adapter/mechanism to register notification-specific event triggers in the form of fgcommands.

I was merely trying to point out that this is indeed one of those few cases where can have our cake and eat it, without requiring tons of new code.

This realization is primarily due to Torsten's Phi/mongoose groundwork in the light of the Qt5 debate, because he stated on several ocassions that it would indeed be possible for Phi to re-interpret our existing PUI/XML dialogs as long as those are not using any Nasal blobs, but only fgcommands.

Torsten's conclusion is in line with my own experiments relating to the "pui2canvas" parser: if people had realized this much earlier, we could have introduced custom fgcommands for all sorts of different purposes (even they were to be implemented in Nasal), and could get rid of PUI/XML much more easily - what is complicating matter tremendously now is the degree of Nasal blobs all over the place in fgdata, i.e. the "free-form nature" of just dropping some magic piece of Nasal code anywhere to implement a feature, because there is no well-defined mechanism in place that is formalized anywhere, which is why it is ton of work to do away with PUI/XML without also parsing the existing markup, including specifically those problematic Nasal blobs.

Now, fgcommands are admittedly are fairly simple and crude, but they are sufficiently generic in nature for triggering events, and they don't depend on Nasal - but it is trivially possible to expose existing Nasal code as an fgcommand by registering a custom callback via the addcommand API (which was a clever idea that James came up with originally).

Thus, given the constraints we're facing, I think that the fgcommand-based route is worthwhile to discuss/explore and maybe even pursue, even if just to make sure that future efforts are not facing the same challenges that we're currently facing (referring to the degree of Nasal blobs embedded in all sorts of XML files in the form of "bindings").

Given your own background in the PUI/XML and Nasal department (e.g. joystick config UI, tutorials, checklists, airports.xml), I think that you can relate to the dilemma here - and given your HLA/RTI related experiments, I assume that you can see the power of encapsulating such Nasal blobs via the fgcommand API, which also means at the same time that an IPC mechanism like Emesary (but also any other if/when the need arises) can be trivially adopted just by wrapping the fgcommand factory helpers used by the event triggers (in the bindings)

Obviously, a dedicated mechanism better designed to deal with IPC requirements could be just as well added eventually - but the fgcommand system is simple enough to "just work", and it does not require any C++ changes or long discussions/code reviews on the devel list, it's using a really simple but well-tested extension mechanism, that is ideally suited to encapsulate Nasal blobs by registering them as fgcommands. Which makes such Nasal code implicitly available to any other mechanism able to invoke fgcommands.

However, like you said, it may be premature to look at this right now - still, if you are interested in this, my suggestion would be to make sure that your bindings are at most calling a single Nasal function that is included via io.include() - that way, the corresponding bindings can trivially be wrapped via an fgcommand/addcommand layer that registers theses callbacks and makes them available as fgcommands.

And that is actually another idea I discussed with Richard: having a vector that contains hashes specififying the notifications, including human-readable strings for UI labels/tooltips and descriptions - because once we have that, we can procedurally create a GUI with buttons to control MFDs, purely based on having a list of supported notifications with a little meta information.

I think, you will quickly come to appreciate the flexibility that this approach offers, especially once you imagine dealing with multiple independent instances of your new MFD, which would currently entail having to review/patch each binding in your dialog, right ?

As a matter of fact, I have found that to be tremendously useful when shaping such an API, because it helps to get rid of hard-coded assumptions that may break down once independent/separate instruments are running. That is one of the reasons why most Nasal/Canvas code I have been sharing here does indeed support independent instances of the underlying display, using a procedurally-created UI for each instance.

However, my sole motivation for suggesting this here is that you said you were interested in efforts like FGQCanvas, realizing that actually implementing event handling support in a generic fashion could be tedious - the fgcommand route however will "just work", and without being specific to FGQCanvas - it could just as well by used by Torsten's Phi UI, or tablet PCs, mobile phones, Rasberry PI hardware or dedicated Saitek hardware - without any of those front-ends having to deal with niche-technologies like Nasal and/or Emesary.

Besides, if/when the FG1000 can be told to create independent instances, that will be an excellent stress-test for various Canvas/Nasal related parts, but also for the Emesary system.

So, this could prove to be a huge asset when benchmarking the various systems involved here, and optimizing them further. Furthermore, it will be much easier to tell separate fgfs instances to hook up different FG1000 instances in master/slave or multiplayer/shared-control setup.

Thus, I do believe that this could also translate into actual improvements to the underlying Canvas C++ code to make sure that the system is indeed capable of running a handful of MFDs without sacrificing too much performance, which is also why I previously suggested to consider what needs to be changed to provide a Canvas GUI widget wrapping your FG1000 work - analogous to the MapStructure widget I once created for wrapping the MapStructure MVC framework.

So, it's really not that I am emotionally attached to the fgcommand approach or any of the front-ends this could support (namely Phi/FGQCanvas), but I do care about the multi-instance use-case and what this could mean for the Canvas system and its future. From my standpoint, Emesary notifications wrapped via fgcommands are just the most straightforward mechanism we currently have available without causing a ton of work.

PS: Don't worry about not getting enough feedback, rest assured I will be looking at your code, because I am also highly interested in seeing how we can work out new Canvas features to better support such avionics, specifically with the multi-instance and distributed scenario in mind - which is why I am providing so much feedback ;-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas G1000

Postby stuart » Sat Nov 25, 2017 12:29 am

I've just checked in the first part of the FG1000 implementation, which seeks to emulate the Garmin G1000.

At present only the Navigation Map and Traffic Map pages are implemented, and even those are not complete - a reflection of the complexity of the task!

You can access it within a PUI surround from the Debug menu.

For those who don't want to wade through the G1000 user manual:
- Use the softkeys on the bottom to change what the map displays (currently heavily reliant on web-based maps)
- Use the Range control to zoom the map in and out.
- To change between the Navigation Map and Traffic Map pages, use the FMS control on the right to change the page.

Some of the code is pretty ugly, but I think the overall architecture is sound. I anticipate using Emesary more extensively than at present.

If people are interested in helping out, there's plenty of opportunity to do so in cleaning up the pages, applying the correct styling and creating some of the other pages.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Canvas G1000

Postby Hooray » Sat Nov 25, 2017 6:07 pm

. I'm hoping that once I've got that done I'll have created enough of a framework that the rest of the MFD pages can be created relatively easily without some massive re-factoring effort.


Actually, that's looking really good - but since you are pointing out the amount of work involved in adding more functionality to this, I would suggest to review existing MFDs that could possibly benefit from using this implementation (sooner or later) - for instance, the Avidyne Entegra R9 has tons of functionality not yet available in the FG1000, so this could be a win/win for both efforts - obviously, that would require that the missing bits from the R9 are back-ported to the FG1000, and that existing FG1000 related functionality becomes fully styleable/customizable (which would make certain MapStructure related optimizations available to the R9/extra500).

But looking at the complexity of the R9, that may be the most likely candidate to have an impact on the FG1000, especially if coming up with a generic framework is the declared mid-term goal. And if you find a way to get them involved, that could also mean much less work for both efforts - while making their work more modular, i.e. better reusable.

Image

Regarding the original ND/MapStructure work, I found that the architecture of the required MVC design became more obvious once we had a handful of different aircraft using the framework, using different styles and different front-ends, but also different simulated systems underneath the whole thing, just like the FG1000 is now having an impact on the MapStructure/Canvas systems.

Back then, we would use pre-recorded flights (fgtape) to test different features and just replay flight segments - and then we added support for driving MapStructure layers from AI/MP data, which is another good way to test different features while making sure that there are no hard-coded assumptions. In conjunction with documenting the integration steps, supporting independent instances and different aircraft was the most important decision to get people to adopt that work and provide feedback/get involved.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas G1000

Postby Michat » Thu Nov 30, 2017 1:46 am

Howdy guys.

@Stuart many thanks for your good code (FGHero) contributions to the FG project.

I heard about your G1000 project, and now I'm thinking in to offer my help to you. Being not a great fan of the electronic gadgets on aircraft, but having some basic skills with Inkscape which is the free software I used to play (apart from FG). I love 2D panels and I use to play with those.

Well, Inkscape is very difficult program that I try to control but it uses to control me at times (mostly of the times), especially when I try to buttonize things. Is the only program that I know that you need to get luck to get desire results. The case is that today I get luck and I managed to create a G1000 mock-up in a partial panel design that I wish to share with you if maybe you need help for the case.


Image
My mock-up

Image

Original G1000 as seen in official PDF.

Another thing where I don't have control is the text font, as I use only fonts provided by Inkscape.


29.92 FG'ers
User avatar
Michat
 
Posts: 1226
Joined: Mon Jan 25, 2010 7:24 pm
Location: Spain
Version: 191b
OS: MX 21 Fluxbox oniMac

Re: Canvas G1000

Postby Hooray » Thu Nov 30, 2017 9:09 pm

Thank you, that is really looking good.

I am not pretending to speak on behalf of Stuart - but I do think that this could greatly help reduce the complexity of the GUI dialog.
For instance, once we have a full "skin" (showing the full instrument, except the region for the screen), we can remove the legacy PUI widgets and use conventional bindings.
That would make it possible to use a native Canvas dialog, which also means that separate/independent instances of the dialog can be shown more easily, but that would also mean that other front-ends like Phi/FGQCanvas could use the same approach without having to recreate the UI from scratch.

I think what is needed is a vector image so that we can export that to a raster image using the required resolution, because Stuart mentioned that he wanted to maintain the aspect ratio of the same thing.

Anyway, before doing any further work, it'd be best to wait for Stuart's feedback - I'd imagine that getting the vector images would be useful so that they can be committed to the repository.

Thanks again for helping with this, much appreciated !
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas G1000

Postby www2 » Tue Jan 09, 2018 4:16 am

Stuart i wand to make some comments about wiki article:
everyone agrees we would like to add airspace data - what we’re missing is a suitable data source with the correct license. Torsten found a raster-based source but for wider use in the sim we really need vector data, so we can render it ourselves directly. [17]


There is the navigraph data for littlenavmap that include vector data for airpace and data for atc but i can say that i miss some atc areas as EHAA_CTR and eurocontroll.
But the littlenavmap is easy to implement is only a sqlite file.

According to the Route Manager wiki page, we already have support for SID/STAR data provided from Navigraph, which is released on the AIRAC cycle, and costs a pretty small amount (9 EUR for a single download of FMS data, or 90 EUR per year) Given the relatively low cost, I don't think that we as an organiation want to get into trying to digitize data ourselves just to make it open-source or public domain. Particularly given the low cost of a download. We might want to digitize the STAR/SIDs for the default airport with each release so there are some approaches available for those who don't want to purchase the data.[16]

First I know its is not GPL/CC/ODBL/PB but we can ask navigraph to add a cycle most of the time a few months old as a demo this is the same for x-plane 11 and most of the addons for MSFS X/P3D.

Creation of a foundation is a good idea but i think we to promote free/open source and freely accessible data in aviation.
Beside flightgear, in an later stadium we can run a project for publish our own charts and aeronautical navigation database aka the classic DAFIF database.
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: Canvas G1000

Postby TheTom » Tue Jan 09, 2018 7:47 am

For airspace data we could use https://openflightmaps.org/ . It provides community created navigation data for many countries in (currently only) Europe with a free license.
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: Canvas G1000

Postby Hooray » Wed Jan 10, 2018 2:04 pm

FWIW, right now, Stuart is using raster images (fetched online) - however, both, James and Stuart have discussed the need to include vector data and provide vector drawing capabilities via Canvas - because there are a handful of valid use-cases:

http://wiki.flightgear.org/FG1000#Navdata
http://wiki.flightgear.org/Canvas_Maps#Vector_data

Besides, Thorsten mentioned that we're adding the implicit assumption about being "always-on" when using the tile-map approach to fetch such data, and asked for an "offline-mode" - e.g. by pre-fetching/downloading required data and caching that: http://wiki.flightgear.org/FG1000#Offline_mode

More recently, Richard suggested that Torsten's built-in mongoose work may be able to provide the same data in a self-contained fashion, without end-users having to be online.
Basically, even tile-map based Canvas displays would continue to work, as long as FlightGear's mongoose integration provides the required data:

Canvas MFD framework vs. EFB functionality
Richard wrote:If I were to implement approach plates in the EFB I'd probably use raster images provided via http and provide an http service within FG to do this, or to allow the EFB to use any other external web service. Other content for the EFB could be also provided as SVG via http.


This is actually in line with one of Torsten's earlier proposals to use an atlas-based approach and dynamically create raster images on demand in a background thread for use by the mongoose/phi module:

Atlas still in use ?
Torsten wrote:I'd really like to use the Atlas generated maps as a layer in the browser map. Is anybody out there looking for an adventure and is able to modify the Atlas map generator to generate maps on-the-fly? Input would be three parameters: z/x/y where z is the zoom level and x/y are numeric parameters describing latitude and longitude (based on image size). Output should be a generated tile of 256x256 and format png in a memory buffer.

This could be compiled as a Apache httpd module (like osm's "renderd") or linked against a standalone webserver to akt as a tileserver for any openlayers compatible map.

Torsten


It is also worth noting, that we do have a working patch implemented by ThomasS that registers an arbitrary Canvas texture with Torsten's mongoose work to "stream" it to another process via http:

http://wiki.flightgear.org/Read_canvas_image_by_HTTP
Image

Thus, as usual, it seems we have many bits already in place, just not yet integrated:

http://wiki.flightgear.org/Canvas_Devel ... ter_Vision

https://sourceforge.net/p/flightgear/ma ... /32522423/
James Turner wrote:The HTTP server already does this - if you select a ‘low compression’ image format such as TGA or uncompressed PNGs, it’s very close to what you want. It will be using a local TCP socket, not shared memory, but unless you want really large images, I am not sure the additional complexity is worth adding an entirely new image output system for.

See the code for how to increase the max-fps (defaults to 5Hz but could be 30 or 60Hz) and file-format of the http-server; any image format supported by OSG ReaderWriter plugin should work. (Well, so long as the plugin implements writing!)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas G1000

Postby stuart » Wed Jan 10, 2018 10:41 pm

Hi All,

Apologies for the delay in responding to this. I've been getting on with the FG1000 and it now has a number of working pages (Nearest Airports, Airport Information, Navigation Map, Traffic Map). It's now at the stage where creating a number of the pages (Nearest..., .... Information) should be straightforward. If anyone is interested, please get in touch.

@Michat: Those graphics look really good. As Hooray suggested, could you create the full G1000 surround as a SVG file? That would be great as it would allow me to replace the PUI dialog I'm using at present.

Re: Airspace data. Yes, we definitely want vector data. I'm hoping that we might convince the source of the raster data we're using at present to provide it as raw vector data, but we haven't had any luck so far.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Canvas G1000

Postby Hooray » Thu Jan 11, 2018 12:03 am

stuart wrote in Wed Jan 10, 2018 10:41 pm:@Michat: Those graphics look really good. As Hooray suggested, could you create the full G1000 surround as a SVG file? That would be great as it would allow me to replace the PUI dialog I'm using at present.


FYI: rleibner has been working on a dedicated "skinnable" helper class for these purposes, this includes a simple method for using drag&drop to identify hotspots (buttons) and their coordinates.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Canvas G1000

Postby Michat » Thu Jan 11, 2018 5:23 pm

Hi, all. Today I've accomplished to finished G1000 keyboard that I had almost ready when I published my first mock-up here .
As soon as possible I'll try to attack the main instrument frame as I was waiting for your confirmation, so I left it in the to do list also because is the most difficult element to recreate.


My mock-up.
Image]


Original FMS keyboard pdf

Image


Cheers
User avatar
Michat
 
Posts: 1226
Joined: Mon Jan 25, 2010 7:24 pm
Location: Spain
Version: 191b
OS: MX 21 Fluxbox oniMac

Re: Canvas G1000

Postby wlbragg » Thu Jan 11, 2018 6:09 pm

Wow, that is some nice work!
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7574
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Canvas G1000

Postby Michat » Fri Jan 12, 2018 4:56 pm

Thank you guys. Still there are many differences that you can see at a glance (some buttons tabs and a missing vertical rule in the previous panel), and some other problems at pixel level that I'm trying to solve on this one before to attack the main panel.
User avatar
Michat
 
Posts: 1226
Joined: Mon Jan 25, 2010 7:24 pm
Location: Spain
Version: 191b
OS: MX 21 Fluxbox oniMac

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 0 guests