Board index FlightGear Development Canvas

CompositeViewer, Canvas and windows outside main window

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.

CompositeViewer, Canvas and windows outside main window

Postby Hooray » Sat Jul 25, 2020 4:52 pm

Split off from the topic Piper PA28 Warrior II.


Robertfm wrote in Thu Jul 09, 2020 8:23 pm:
wkitty42 wrote in Thu Jul 09, 2020 8:02 pm:robert, it has to stay within the FG window because it is part of FG... it is not an autonomous window that you can drag anywhere on your screen realestate... if you want to put it on another monitor, you have to make the FG window split across more than one monitor but even then, the FG1000 will still be in the FG window...

So if it can't go to another monitor and can't be reduced in size then as an addon to a non glass cockpit it can't be used because you take up almost the entire view.


Currently, this isn't supported - but it's a long-standing idea, even the implementer of the Canvas system originally mentioned this on the devel list:

https://www.mail-archive.com/flightgear ... 37907.html
Thomas Geymayer wrote:Support multiple views/windows:
Currently the GUI can only be placed inside one view/window (see
Docs/README.multiscreen) but it would be nice to be able to move
windows between views.


Mathias Fröhlich has been wanting to support multiple windows for a single graphics context for a long time, and he foresaw the concrete use-case long before the Canvas system took shape:

https://sourceforge.net/p/flightgear/ma ... /19718354/
Mathias Fröhlich wrote:What we just need is the ability to still redirect some windows to an other display/screen. What would be good to have is the specify a completely different scenegraph in some subcameras. I think of having panel like instruments on an additional screen/display for example.

I would like to be able to still use displays and screens for some parts
of the viewer. So while this would be very good to have and probably better
for the end performance where you are heading to, we should have that as an
addition to the way we can now redirect views to different displays and
screens.

What we just need is the ability to still redirect some windows to an other
display/screen.

What would be good to have is the specify a completely different scenegraph in
some subcameras. I think of having panel like instruments on an additional
screen/display for example.

I have an animation that I call rendertexture, where you can replace a
texture on a subobject with such a rtt camera. Then specify a usual
scenegraph to render to that texture and voila. I believe that I could finish
that in a few days - depending on the weather here :)
The idea is to make mfd instruments with usual scenegraphs and pin that on an
object ...



More recently some contributors have begun toying with CompositeViewer support again: http://wiki.flightgear.org/CompositeViewer_Support

And James specifically said the following a couple of weeks ago about the existing XML-driven WindowBuilder (which is currently not yet available/accessible at runtime):

https://sourceforge.net/p/flightgear/ma ... /37058207/
James Turner wrote:Another idea previously mentioned is to fix up WindowBuilder which can already do multiple windows? (with an XMl driven UI, though: that’s the part that is missing to make it useful at runtime), i.e. extending WindowBuidler to allow changes at runtime might be a better solution [...] because this will keep existing multi-window / multi-view setups working.


From a Canvas standpoint, it would make sense to implement this as a dedicated Canvas placement (see below for details).

In other words, if you care about such features, please do file a feature request so that related comments/patches can be tracked properly.

http://wiki.flightgear.org/Canvas_Popout_Windows
http://wiki.flightgear.org/Canvas_Devel ... ve_Windows

PS: A Canvas placement is roughly 100 lines of boilerplate code: http://wiki.flightgear.org/Canvas_Devel ... Placements And the WindowBuilder method to be invoked is already building windows using the property tree structure: https://sourceforge.net/p/flightgear/fl ... r.cxx#l291 The existing way of using the windowBuilder can be seen here: https://sourceforge.net/p/flightgear/fl ... y.cxx#l796 - however, a non-scene window (GUI) can be dealt with more easily: https://sourceforge.net/p/flightgear/fl ... .cxx#l1048
Last edited by Johan G on Mon Aug 24, 2020 6:20 am, edited 2 times in total.
Reason: Split off from the topic "Piper PA28 Warrior II". Fixing misspelled title.
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: Piper PA28 Warrior II

Postby Hooray » Sat Jul 25, 2020 7:22 pm

In the meantime (i.e. as a compromise), it is possible to stream a canvas (texture) over http to a running browser instance - this won't receive any mouse events "as is" (this would need additional work, or you'd just use a HTML page with some controls to use the mongoose back-end to control the FG1000, which is using Emesary anyway):

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

With that being said, I've previously demonstrated how OSG's ReaderWriter based plugin system can be used to work around hard-coded FlightGear limitations: http://wiki.flightgear.org/Canvas_SVG
Which is to say, in OSG land it's also fairly common to see VNC being used in conjunction with OSG apps - and there is a dedicated ReaderWriter plugin just for VNC support - in other words, with a little, you could get an arbitrary canvas to be served via VNC probably: https://github.com/openscenegraph/OpenS ... terVNC.cpp
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: Piper PA28 Warrior II

Postby Hooray » Sun Aug 23, 2020 7:25 pm

Piper PA28 Warrior II
Robertfm wrote:
wkitty42 wrote in Thu Jul 09, 2020 8:02 pm:robert, it has to stay within the FG window because it is part of FG... it is not an autonomous window that you can drag anywhere on your screen realestate... if you want to put it on another monitor, you have to make the FG window split across more than one monitor but even then, the FG1000 will still be in the FG window...


So if it can't go to another monitor and can't be reduced in size then as an addon to a non glass cockpit it can't be used because you take up almost the entire view.


FWIW, there's recently been some experimental work done by Jules Smith (cgdae on the forum), who's been working on CompositeViewer support - which basically means rendering multiple independent scene views to different "windows", which includes rendering to sub-windows, but also external OSG-level windows.

In the process, James encouraged Jules to review Tim's original WSA window builder routines, which currently work through PropertyList-XML "only":

https://sourceforge.net/p/flightgear/ma ... /37058207/
James Turner wrote: can’t our WindowBuilder already do multiple windows just fine? (with an XMl driven UI, though : that’s the aprt that is missing to make it useful at runtime)

I think extending WindowBuidler to allow changes at runtime might be a better solution than using osgCompositeViewer, becuase this will keep existing multi-window / multi-view setups working. My guess is if we switch to osgCompositeViewer, we might break some of those.


A couple of days later, Jules worked out how to invoke the code mentioned by James at run-time and put the corresponding code into a dedicated fgcommand to clone views dynamically and create dedicated OSG windows for each cloned-view:

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

While Jules' original goal is still very much work-in-progress, he has now "accidentally" discovered how to invoke the window builder routines dynamically, as per James' suggestion.

And this happens to be the exact same code paths required to also render an arbitrary Canvas FBO (texture) into a dedicated window, including MFDs like the FG1000.

In other words, we now have all the missing bits to actually add a dedicated Canvas placement for external/separate OSG windows, which is a long-standing feature request: http://wiki.flightgear.org/Canvas_Devel ... ve_Windows

Additional pointers are collected here: http://wiki.flightgear.org/Canvas_Popout_Windows

Note that once Jules continues making progress with CompositeViewer support, it's going to become increasingly feasible to also run entire Canvas MFDs (rendering + underlying Nasal code) outside the main loop, especially the ones that use encapsulated access to key FlightGear APIs (fgcommands and extension functions), which incidentally applies to the FG1000 because it happens to use Richard's Emesary framework.
At that point, a background thread (Nasal or SGThread) could run the relevant FGNasalSys instance without having to run inside the main loop. Re-structuring the FG1000 accordingly is going to be much easier in comparison to trying this with other MFD code like the NavDisplay stuff, because it's using a much more modular structure so that identifying the few remaining use-cases where fgcommands and extension functions are still invoked directly (rather than going through Emesary) can be easily done, and easily updated, too.


Also, this is in line with Tim Moore's comments:

https://sourceforge.net/p/flightgear/ma ... /36295606/
Tim Moore wrote:I think that most other uses of cameras during
rendering -- for example, render to texture cameras for effects -- are best
handled by slave cameras with independent views as well.



Fernando recently summed up the current situation when he posted this:
https://sourceforge.net/p/flightgear/ma ... /37089780/
Icecode GL wrote:It would make sense to integrate all efforts (CompositeViewer, Canvas
and Compositor) to create a Canvas Element that can render an
arbitrary view.

Some time ago I wrote what I think are the required steps to get
something like cockpit mirrors working:
http://wiki.flightgear.org/Canvas_View_ ... nt#Roadmap

The main showstopper was having CompositeViewer support, but since
that effort is underway, all the parts are there for someone willing
to dive in.

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: Piper PA28 Warrior II

Postby Robertfm » Sun Aug 23, 2020 7:43 pm

So does this mean there will be a simple code in settings that will allow FG1000 to be dragged and resized in on a separate monitor
Robertfm
 
Posts: 1721
Joined: Thu Apr 25, 2019 5:56 pm
Callsign: RFM1
Version: 2020.3.11
OS: W10 v 19041.746

Re: Piper PA28 Warrior II

Postby Hooray » Sun Aug 23, 2020 7:50 pm

I guess it depends - your best chance is obviously if you are able to patch/rebuild fgfs from source - because then you won't be limited by the spare time that developers can put into developing/integrating this further.

In other words, you'd want to look at Jules' fgcommand and strip that down to just the window creation bit and where you specify the scene's root.
The next step is adding a geode for the canvas, for which we have existing code, too - i.e. in other canvas placements.

All in all, it's likely to be less than 50 lines of C++ code, and we can certainly work out the necessary bits here on the forum.

Other than that, you'd be well-advised to file a proper feature request so that this can be separately tracked.

On the other hand, you might be lucky because Stuart didn't only develop the FG1000, but he also happens to be a core developer - so that he might be able to provide additional pointers or even offer his help to get this integrated (assuming he's interested in seeing this capability).

Using the approach taken by Jules, this could be implemented as a simple fgcommand, so that the Canvas window could show a button or use keybinding to open a dedicated "pop out" window,.

The relevant portions of Jules' work can be seen here:
cgdae wrote:This is accessible using the new Nasal command
"view-clone", which is implemented by a new method,
src/Viewer/viewmgr.cxx:FGViewMgr::clone_current_view(): this creates a new
top-level window with a copy of the Flightgear main window's current view's
eye position and eye direction. Currently the new window's eye position and
direction are constant, regardless of what happens to the main window's
view. In the future the intention is that the eye position/direction
change depending on what the original view was (e.g. if Pilot view, eye
position/direction would follow the aircraft).

https://sourceforge.net/u/cgdae/flightg ... r.cxx#l212


You'd obviously want to use an alternate scene root, i.e. add a Node with the Canvas geode: https://sourceforge.net/u/cgdae/flightg ... r.cxx#l251

In other words, adding a new "open-window" fgcommand that takes a prop.Node with arguments to specify the scene root (canvas texture) would be comparatively straightforward thanks to the groundwork completed by Jules.

This could then be honored either as a startup/runtime setting or by showing a corresponding button to move a window out of the main fgfs window.
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: Piper PA28 Warrior II

Postby Robertfm » Sun Aug 23, 2020 8:00 pm

As I have said many times before this is all beyond me and I appreciate all the hard work the Devs do. Surfer Tim developed a 6 pack panel and a radio panel that could be moved between monitors using Python.
Robertfm
 
Posts: 1721
Joined: Thu Apr 25, 2019 5:56 pm
Callsign: RFM1
Version: 2020.3.11
OS: W10 v 19041.746

Re: Piper PA28 Warrior II

Postby Hooray » Sun Aug 23, 2020 8:07 pm

For the sake of completeness, the FG1000 isn't "just an instrument" - it's basically a whole software package (and so is the real thing), so moving that to a separate monitor/machine is quite a bit more complex due to hard-coded assumptions (e.g. Nasal, OSG, OpenGL, OpenVG).

In other words, without rewriting the whole thing, the best option to show the FG1000 in a separate window is indeed the aforementioned feature to "stream" the texture over http, or indeed use the approach I outlined a few postings earlier, which will indeed require some C++ work.

However, if you consider yourself mainly an end-user, you are obviously free to file a feature request, even if just to offer your help in testing the feature if/when it arrives: https://sourceforge.net/p/flightgear/codetickets/

Like I said, it's probably going to be implemented sooner or later, simply because it makes sense for a number of reasons - one of which is OPTIONALLY moving complex avionics out of the main window, but also out of the main loop (thread).

Also, like I mentioned, the FG1000 is basically an ideal test bed for this, because of it's encapsulated structure and internal use of Emesary, which makes it straightforward to encapsulate remaining hard-coded assumptions, and really move the logics out of the main loop, too.
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: Piper PA28 Warrior II

Postby Robertfm » Sun Aug 23, 2020 8:15 pm

I have put in a ticket.
Robertfm
 
Posts: 1721
Joined: Thu Apr 25, 2019 5:56 pm
Callsign: RFM1
Version: 2020.3.11
OS: W10 v 19041.746

Re: Piper PA28 Warrior II

Postby Hooray » Sun Aug 23, 2020 8:25 pm

The way you have now phrased your feature request, you make it sound like it's specific to the FG1000, and you'll probably also be told to consider trying fgqcanvas, which is a standalone canvas client that re-implements a subset of the Canvas system out-of-process :wink:

http://wiki.flightgear.org/FGQCanvas
Image
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: Piper PA28 Warrior II

Postby Robertfm » Sun Aug 23, 2020 8:40 pm

Am I correct in assuming you can only run one 'canvas' on 8080 at a time. I use Phi all the time. Where do I actually find the displayed panel the link in the wiki about this doesn't work.
Robertfm
 
Posts: 1721
Joined: Thu Apr 25, 2019 5:56 pm
Callsign: RFM1
Version: 2020.3.11
OS: W10 v 19041.746

Re: Piper PA28 Warrior II

Postby Hooray » Sun Aug 23, 2020 8:45 pm

Phi is using a mongoose based web browser that runs in a background thread, as such you can open multiple instances (browser) and it will indeed work.
However, using fgcanvas itself is a separate issue, simply because it's definitely not 100% compatible, i.e. it is indeed a re-implementation of the canvas system, that comes with its own pros & cons.

That being said, fetching the rendered texture to show it in a separate window/browser (or on a separate machine/device), will "just work".

http://wiki.flightgear.org/Read_canvas_image_by_HTTP
Image
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: Piper PA28 Warrior II

Postby Robertfm » Sun Aug 23, 2020 8:50 pm

However you still don't give link to use, if it works.
Robertfm
 
Posts: 1721
Joined: Thu Apr 25, 2019 5:56 pm
Callsign: RFM1
Version: 2020.3.11
OS: W10 v 19041.746

Re: Piper PA28 Warrior II

Postby Hooray » Sun Aug 23, 2020 8:58 pm

Seriously, this is like the 3rd time that this option was mentioned - why don't you try to pay more attention, e.g. to the URL shown in the screen shot ??

For the proper canvas index, refer to the property browser /canvas/by-index/...)

https://sourceforge.net/p/flightgear/fl ... andler.cxx
https://sourceforge.net/p/flightgear/fl ... 6cca944f6/

PS: Feel free to update the wiki as needed, hint: the required URL is /canvasimage ...
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: Piper PA28 Warrior II

Postby Robertfm » Sun Aug 23, 2020 9:17 pm

I pay attention the wiki page says right at the bottom that this feature may not work. I will give it a try tomorrow.
Robertfm
 
Posts: 1721
Joined: Thu Apr 25, 2019 5:56 pm
Callsign: RFM1
Version: 2020.3.11
OS: W10 v 19041.746

Re: Piper PA28 Warrior II

Postby Hooray » Sun Aug 23, 2020 9:28 pm

That's outdated, it's been committed a while ago -see the links I posted.
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

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 3 guests