pommesschranke wrote in Fri Jan 31, 2014 2:52 pm:Technically, 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
I am interested.
It would be very nice to have PFD & ND on my tablet or a small LCD driven by RaspberyPi
We have other folks interested in running such things on Android devices or mobile phones:
Subject: using FGpanel to display various instruments and electricssomeguy wrote:I'm waiting for someone to write an app that will display instruments on an iPad over wifi or Bluetooth, or even USB, while the rest of the simulation runs on my Mac. Naturally, the controls would respond to touch gestures.
So it would make sense to coordinate such efforts, because the requirements will be very similar.
Even some core developers discussed this on the devel list:
http://wiki.flightgear.org/Howto:Optimi ... .2F2013.29For example, see:
http://wiki.flightgear.org/Howto:Optimi ... le_devicesThe Canvas is a property tree-based subsystem using listeners, the canvas is primarily a wrapper on top of Shiva and OSG that is invoked via listeners.
So all the OpenGL code is either located in Shiva or in OSG - OSG can be told to use OpenGL ES.
So it would be a matter of experimenting with it.
For this particular project, I would suggest to extract the Canvas into a standalone executable - something like this has been previously done by TorstenD when he came up with FGPanel, he "just" extracted FlightGear's 2D panel code and turned it into a standalone binary.
This alone would help us ensure that we can optimize the canvas to support OpenGL ES - once that is working, you could cross-compile the standalone canvas binary.
Technically, this will involve some -but not all- of the steps outlined at:
http://wiki.flightgear.org/FGCanvas(not all of them, because FGCanvas is eventually intended to be merged back into the main code base)
TheTom already prepared the Canvas subsystem to be used outside FG, see:
http://wiki.flightgear.org/CanvasThe canvas system has been refactored such that it can be more easily re-used in other programs, this included moving the Canvas component from FlightGear to SimGear and releasing the canvas code under SimGear's license (LGPL).
It is now possible to use the Canvas in projects unrelated to FlightGear, but you will obviously benefit from using certain FlightGear-related technologies, such as an 1) property tree 2) SGSubsystem-based main loop, 3) an osgviewer-based main window, and 4) Nasal scripting.
Icecode's FGRadar project is such a completely separate code base from FG, which uses SG/FG components to simplify code reuse, without re-inventing the wheel.
For this very purpose, FGRadar uses a custom "SGApplication" framework - so that existing FlightGear subsystems can be more easily reused in different projects. All that's needed is deriving your own class from "SGApplication" and implementing its interface. The whole idea behind "SGApplication" is to provide a scriptable framework for OpenGL applications, fully based on 1) OSG, 2) SGSubsystems, 3) Nasal scripting and 4) the Canvas.
Technically, another thing needs consideration, for technical reasons:
http://wiki.flightgear.org/CanvasBeginning with 2.8, up to 2.99+, all FlightGear versions require FBO support for the canvas system to work properly [1]. In particular, this means that very old GPUs such as Intel 910/915 cards are currently not supported (FBO support is obviously also required for Rembrandt to work).
Unless render-to-texture (RTT) support can be provided through some form of fallback mode for hardware without FBO support, we we might need to consider officially un-supporting such old hardware from 3.0 (since we can already detect the vendor as Intel).
It seems 940-class chips are okay, and the 2000/3000/4000HD versions seem to work, but the earlier 9xx and before are going to be problematic for the time being [2]. At the moment, it isn't clear if telling the od_gauge/OSG backend code to use pbuffer rendering instead of FBOs would already help solve the problem [3].
This should give you a rough idea on what's involved in extracting the canvas system into a separate code base, to cross-compile it for other devices.
Basically, the steps are:
- use the FGPanel/FGRadar or SGApplication code base to come up with a SGSubsystem-based program
- add the Nasal, events (timers) and property tree subsystems
- add the canvas system
- check where OpenGL ES is not yet supported, report issues or fix them directly
- come up with workarounds regarding the FBO issue
40-60% of this are already done inside FGPanel and FGRadar - so the first weekend will be primarily spent doing "copy & paste".
If you are interested in working on this, you should obviously know some C++ and you should be able to build from source.
If that's not a problem, I suggest to raise the question in the canvas forum, so that TheTom can provide some more informed input.
It would definitely be a useful project, not just for Rasberry PI support, but for FG itself - because the whole FGPanel/FGCanvas idea is generally agreed to be useful, so any work related to this would be highly appreciated, and we're here to help you accordingly.