Canvas Nasal/JavaScript Subset: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 37: Line 37:


|}
|}
<syntaxhighlight lang="nasal">
var new_function =  func(keyword) {
return
  func(name, params, body)
  print("var ", name, "=", keyword, "(",params,")", body);
}
var make_nasal_function = new_function('func');
var test = make_nasal_function(name: "hello", params: "name", body: "print(name);");
</syntaxhighlight>


== Goals ==
== Goals ==

Revision as of 16:33, 17 September 2014

This article is a stub. You can help the wiki by expanding it.
WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.
Note  If you're interested in helping with this, just get in touch with Hooray and TheTom.


Objective

Determine if it's feasible to come up with a safe subset of Nasal and JavaScript for sharing animation/update logic for SVG-based instruments that may be either implemented by the built-in Mongoose httpd or by the Canvas subsystem. Almost certainly, this would be a very restricted subset of Nasal, and even more so, of JavaScript - but there's really only a handful of functions that cannot be directly mapped to their corresponding equivalents in the other language. Internally, more complex constructs would be handled by JavaScripts eval() API or Nasal's compile(). So this would involve a fair bit of meta programming - primarily, we'd need building blocks to deal with animated SVGs. Internally, a Canvas should then be dealt with like a SVG, i.e. no direct usage of CanvasText/CanvasPath. As long as these are set up via the SVG file and turned into a Canvas property tree, we can easily serve the same SVG file to a web browser over http.

Some kind of animation framework could then rewrite the animation logic to be valid JavaScript, so that the httpd can serve the code to the browser - while Canvas would internally keep using Nasal.

Background

Given the recent mongoose/httpd work, we've been seeing some overlapping functionality that's already available in Nasal space, for which Torsten specifically implemented JavaScript wrappers, i.e. to expose the Property Tree and its listeners to JavaScript.

One idea we discussed is to "compile" Nasal into Javascript and send it to the browser (together with the canvas as SVG), but we don't know yet if this is possible with a reasonable effort. Also we should ensure that the JavaScript API and Nasal API are identical, such the code can be easily converted/ported. So we need to define a safe subset of Nasal and JavaScript and come up with corresponding classes to wrap identical stuff. And there are a quite a few useful JS features that Nasal will never support, so we need to use factories for those to hide differences between both languages (sounds like something that Philosopher might enjoy), or someone will end up complaining that jQuery breaks Nasal...


Mapping

Note  we should take a look at the existing JavaScript wrappers for props.nas etc)


Nasal JavaScript Comments
var var
func function
call()/compile() eval()
settimer/maketimer setTimeout()
props.nas jQuery/WebSockets


var new_function =  func(keyword) {
return 
  func(name, params, body) 
  print("var ", name, "=", keyword, "(",params,")", body);
}

var make_nasal_function = new_function('func');

var test = make_nasal_function(name: "hello", params: "name", body: "print(name);");

Goals

Come up with a common Nasal/JavaScript subset that works in both environments (browser/fgfs), and use factories for hiding platform differences, for example:

  • property tree
  • listeners
  • props.nas

For reference, look at TorstenD's WebGUI work which is heavily overlapping with props.nas stuff. However, we need to keep in mind that there are certain APIs that will never be supported out of the FG context, while others may simply be "delegated" via FlightGear (webSockets, e.g. timers/listeners).

So we kinda need to formalize both environments and come up with a minimal API subset that supports versioning.

We also need to keep in mind that props.nas may be updated using cppbind sooner or later to reduce Nasal space overhead.

APIs

  • setprop/getprop
  • setlistener
  • settimer

(it might make sense to directly encapsulate those APIs and use helper objects, as discussed on the forum)

Design

Mongoose-based FGPanel

Cquote1.png I have been dreaming of a cross-platform, simple

solution to render 2d panels on a remote device.

I have just succeeded with my first partial implementation of a EFIS PFD
rendered in a web browser using nothing but existing web standards and a
running FlightGear instance having the internal web server enabled.

The EFIS is created from scalable vector graphics (svg), is animated by
JavaScript and driven by properties from FlightGear over websockets.
The same svg files that are used for the FlightGear internal canvas
based instruments can also be used for the browser based display, so
both instruments (that of the 3d model and that in your browser) look
100% alike. Websocket properties are exchanged at frame rate making
animations as smooth as they can get. Because it uses SVG, instruments
are always rendered at the highest available resolution of the device
without scaling artefacts.


— Torsten Dreyer (2014-09-17). [Flightgear-devel] Goodbye fgpanel - hello fgpanel 2.0.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png It runs on any device that has a web browser. So yes, if your FlightGear

computer can run Firefox, Opera or alike you can run it on the same
computer, too.
It is not related to the "classical" way of rendering instruments within
flightgear, so everything in this area works as before.

Probably a video is more descriptive, here is a shot of an earlier
(incomplete) version:
http://youtu.be/sYM7uiWIprc
You can see a FlightGear instance on the top right of the big monitor
and Firefox on the left showing the EFIS. Both run on the same computer.
Below the monitor are an old iPod touch (left) and a Nexus 7 (right),
both running the EFIS as a web-app in full screen mode connected over WLAN.
The EFIS in the FlightGear window is based on Canvas/Nasal. The other
EFISes are 100% Nasal free, just HTML/SVG/CSS/JavaScript


— Torsten Dreyer (2014-09-17). Re: [Flightgear-devel] Goodbye fgpanel - hello fgpanel 2.0.
(powered by Instant-Cquotes)
Cquote2.png