Board index FlightGear Development Canvas

MapStructure styling

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.

MapStructure styling

Postby Hooray » Sun May 11, 2014 9:44 pm

Subject: NavDisplay & MapStructure discussion (previously via PM)
Philosopher wrote:@H: I was thinking of working on the styling a bit more - supporting that I think will be key for diverse uses. Once I start loading files by extension, we should be able to have say both a VOR-ND.symbol and a VOR-MAP.symbol yet use the same VOR.lcontroller. Similarly, styles and other options (e.g. radio or autopilot properties) should be doable, and I know we have stubs for these right now, it's a matter of using them.


Subject: Porting the map dialog for 3.2
Philosopher wrote:I'm even debating moving styles from layers to symbols maybe? That is where they are actually used, and would eliminate the ugly "me.layer.style" pattern. Adding helpers would be good.[/list]

Styling needs to occur better and files can usually be simplified.



Referring to the gitorious discussion about having a SVGSymbol class - that is something that will be hard to support/integrate with pre-defined styling unless we patch svg.nas to accept a list of optional SVG attributes that are mapped to a transformation/rewrite-callback so that SVG attributes can be dynamically "rewritten" by the parser based on looking up a certain id and changing CSS stuff there.

For instance, imagine a 2D symbol depicting an ILS (could only find a 3D view):
Image

This could then use id settings like "glideslope" and "localize" to make those elements accessible, the parser would check its lookup map if the current element matches any key, and if so applies the callback to rewrite the corresponding tag to transparently re-style things without having to modify the actual file. People wanting to change the representation would then merely need to copy the SVG file and ensure that they use the same IDs that are required by the layer's style
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: MapStructure styling

Postby Philosopher » Sun May 11, 2014 10:04 pm

For SVGs I just was thinking that, unless we enforce a standard size (so it just fits) or dynamically scale it to fit (aka render, get bounding box, scale, render again, use), the caching won't work well because we rely on fixed sizes (32x32 right now, because that was what VOR fit into, IIRC).

On the other side, the simplest method for caching drawing functions would be a request system that renders the relevant style properties to a string and hashes that, so it can keep track of what has been already rendered. This won't GC or reference count or anything, so it will keep adding up (like intern'ed symbols do in Nasal...), but it will be an easy solution for storing different styles.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: MapStructure styling

Postby Hooray » Sun May 11, 2014 10:21 pm

I think our SymbolCache is just instantiated to be 32x32 currently, I think it does support other dimensions, I actually experimented with using 256x256 for having 4 airports cached, each with their runways/taxiways/parking etc rendered to a single row, so that such cache entries could be reused by multiple dialogs or instruments to be more canvas friendly.

My idea would be to keep it simple and request to maintain certain fixed dimensions for certain symbols, and use fixed lookup-keys (ids) for certain elements - kinda like an "interface" to keep things addressable and manageable for the framework, e.g. navaid symbols must be 32x32, cartographic stuff 128x128 etc.

And like you say, a straightforward assumption would be to always resize things and communicate that upfront, so that people know that their navaid symbols will end up being 32x32 :-)


right, integrating style-able symbols and caching would require custom stuff to be encoded in a fixed order, all lower-cased and then uses as a lookup key, I think we once talked about that on the wiki.

I don't consider stuff adding up a problem as long as we die() on too many entries, and as long as we handle reset/re-init to purge things.
For airport caching I was thinking of having a FIFO queue in a vector that would be sliced - the request system would update stuff based on map/ND requests to render certain airports, and store/provide cached entries for each complex layer. And runways would be straightforward to decompose and assemble from cached building blocks generally, taxiways are a b*ch for other reasons ... but Tom once said that he was considering having "persistent" canvases that are cached on disk - such stuff could even be prepared in some kind of background thread if we were to use a separate/private props.Node.new() that isn't accessed from anywhere else, we would just need a way to register a new property tree with the canvas system from a background thread. :mrgreen:
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: MapStructure styling

Postby Hooray » Mon May 12, 2014 10:29 am

I'm even debating moving styles from layers to symbols maybe? That is where they are actually used, and would eliminate the ugly "me.layer.style" pattern. Adding helpers would be good


right, this really is where they belong - a style is not at all lcontroller specific, it is really only ever used by the symbol file - and you mentioned on gitorious that we could share/reuse lcontrollers with different symbol files, which is another good thing to support - at which point it makes sense to encapsulate styling with each symbol, because having styling stuff in lcontroller files that use different symbol files makes little sense ...
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: 11329
Joined: Tue Mar 25, 2008 8:40 am


Return to Canvas

Who is online

Users browsing this forum: No registered users and 16 guests