Re: [Flightgear-devel] Airport selection feedback
Am 21.09.12 22:45, schrieb Thomas Geymayer: Am 2012-09-21 21:16, schrieb Stuart Buchanan: On Thu, Sep 20, 2012 at 11:44 PM, Thomas Geymayerwrote: I've now changed the default fill rule from even-odd to non-zero. Should probably work better now... Surprisingly, this didn't seem to make any difference. I've included the patch below if you want to check yourself. The problem was that ShivaVG simply hasn't implemented it :) I've now extended ShivaVG to support some kind of a non-zero fill rule. It's not really non-zero because instead of incrementing and decrementing depending on the orientation of the drawn overlapping regions it simply checks if at least a single region covers a pixel. For our use cases it should be enough tough. Hi Tom Are there some plans to integrate some kind of a webview to the canvas ? I remember there was some discussion about. In case there comes a webview the mapserver could provide pre-drawed and referenced tiles as images for a background and i.e. only the plane(s) needs to be drawn. Common maptools on a server based on the same data could be used (I’m using mapnik myself) and I guess one don’t need to be online all the time with possibilities of subversion and/or offline caching probably ? Just as an idea to save drawing resources. -Yves -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport selection feedback
Am 2012-09-22 11:37, schrieb HB-GRAL: Are there some plans to integrate some kind of a webview to the canvas ? I remember there was some discussion about. Yes, this is definitely something I want to support. Maybe in a first step just a tiled map from files on the hard disk, but later also fetching from an url should be possible. It should also be possible instead of directly fetching the tiles from FlightGear just running an external application which puts the files in a folder where FlightGear finds them. In case there comes a webview the mapserver could provide pre-drawed and referenced tiles as images for a background and i.e. only the plane(s) needs to be drawn. Common maptools on a server based on the same data could be used (I’m using mapnik myself) and I guess one don’t need to be online all the time with possibilities of subversion and/or offline caching probably ? Just as an idea to save drawing resources. I am also thinking about some kind of one-time canvas, where the contents are just rendered once and afterwards can be used in an other canvas as a texture and maybe even stored on the hard disk an reused the next time FlightGear is started up. Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport selection feedback
On Thu, Sep 20, 2012 at 11:44 PM, Thomas Geymayerwrote:
I've now changed the default fill rule from even-odd to non-zero. Should
probably work better now...
Surprisingly, this didn't seem to make any difference. I've included
the patch below
if you want to check yourself.
-Stuart
diff --git a/Nasal/canvas/map.nas b/Nasal/canvas/map.nas
index 8aaeab8..53c41cf 100644
--- a/Nasal/canvas/map.nas
+++ b/Nasal/canvas/map.nas
@@ -76,38 +76,45 @@ var AirportMap = {
me.grp_apt = layer_runways.createChild(group, apt- ~ me._apt.id);
# Taxiways drawn first so the runways and parking positions end up on top.
-if (me._display_taxiways)
+if (me._display_taxiways and (size(me._apt.taxiways) 0))
{
+ # For efficiency we create all taxiways as the same path object,
+ # and assume they all have the same surface.
+ var clr = SURFACECOLORS[me._apt.taxiways[0].surface];
+ if (clr == nil) { clr = SURFACECOLORS[0]};
+
+ var icon_taxi =
+me.grp_apt.createChild(path, taxi)
+ .setStrokeLineWidth(0)
+ .setColor(clr.r, clr.g, clr.b)
+ .setColorFill(clr.r, clr.g, clr.b);
+
+ var cmds = [];
+ var coords = [];
+
foreach(var taxi; me._apt.taxiways)
{
-var clr = SURFACECOLORS[taxi.surface];
-if (clr == nil) { clr = SURFACECOLORS[0]};
-
-var icon_taxi =
- me.grp_apt.createChild(path, taxi)
-.setStrokeLineWidth(0)
-.setColor(clr.r, clr.g, clr.b)
-.setColorFill(clr.r, clr.g, clr.b);
-
var txi = Runway.new(taxi);
var beg1 = txi.pointOffCenterline(0, 0.5 * taxi.width);
var beg2 = txi.pointOffCenterline(0, -0.5 * taxi.width);
var end1 = txi.pointOffCenterline(taxi.length, 0.5 * taxi.width);
var end2 = txi.pointOffCenterline(taxi.length, -0.5 * taxi.width);
-
-icon_taxi.setDataGeo
-(
- [ canvas.Path.VG_MOVE_TO,
-canvas.Path.VG_LINE_TO,
-canvas.Path.VG_LINE_TO,
-canvas.Path.VG_LINE_TO,
-canvas.Path.VG_CLOSE_PATH ],
- [ beg1[0], beg1[1],
-beg2[0], beg2[1],
-end2[0], end2[1],
-end1[0], end1[1] ]
-);
+
+append(cmds,
+ canvas.Path.VG_MOVE_TO,
+ canvas.Path.VG_LINE_TO,
+ canvas.Path.VG_LINE_TO,
+ canvas.Path.VG_LINE_TO,
+ canvas.Path.VG_CLOSE_PATH);
+
+append(coords,
+ beg1[0], beg1[1],
+ beg2[0], beg2[1],
+ end2[0], end2[1],
+ end1[0], end1[1]);
}
+
+ icon_taxi.setDataGeo(cmds, coords);
}
if (me._display_runways)
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport selection feedback
Am 2012-09-21 21:16, schrieb Stuart Buchanan: On Thu, Sep 20, 2012 at 11:44 PM, Thomas Geymayerwrote: I've now changed the default fill rule from even-odd to non-zero. Should probably work better now... Surprisingly, this didn't seem to make any difference. I've included the patch below if you want to check yourself. The problem was that ShivaVG simply hasn't implemented it :) I've now extended ShivaVG to support some kind of a non-zero fill rule. It's not really non-zero because instead of incrementing and decrementing depending on the orientation of the drawn overlapping regions it simply checks if at least a single region covers a pixel. For our use cases it should be enough tough. I have also added some more performance improvements: Now the texture is only redrawn if something has changed. So if you don't change the map there shouldn't be any noticeable performance impact anymore. Also the bounding boxes are now only written to the property tree if they are recalculated. This should take some fair amount of changing properties away. With your changes to put everything into one object now zooming takes much more time. Seems like now tessellating takes much longer than before due to the amount of data in one single path. The current problem with zooming is that every position of every path gets recalculated with the updated projection, even though this isn't really needed as the projection doesn't noticeably while just zooming and scrolling around at a single airport. To improve this I want to implement some kind of one-time projected path which after the initial geographic projection only gets scaled and translated instead of completely recalculated. Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport selection feedback
On Fri, Sep 21, 2012 at 9:45 PM, Thomas Geymayer wrote: With your changes to put everything into one object now zooming takes much more time. Seems like now tessellating takes much longer than before due to the amount of data in one single path. The current problem with zooming is that every position of every path gets recalculated with the updated projection, even though this isn't really needed as the projection doesn't noticeably while just zooming and scrolling around at a single airport. To improve this I want to implement some kind of one-time projected path which after the initial geographic projection only gets scaled and translated instead of completely recalculated. Sounds good. Unfortunately a recent Ubuntu update has given me the following errors for all OpenGL applications: Error: Not able to create requested visual. getDefaultWindow: failed to create GraphicsContext I'm currently upgrading to 12.04LTS, which I'm hoping will resolve the problem, so don't expect many improvements this evening! -Stuart -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport selection feedback
(Moving this discussion the the mailing list!) On 20 Sep 2012, at 10:24, Stuart Buchanan wrote: One thing I noticed is that the performance has taken quite a hit from adding the taxiways, as each taxiway segment is being drawn as a separate object. Thomas - any chance we could have a draw mode to allow a set of Quads to be defined? Right, don't forget we can build Canvas elements from C++ - we could have helper methods on the Nasal API which create a map layer automatically from an ICAO code. I may end up doing this for the route-path in the map widget, depending on performance. related - 'best-runway' is selected, show what the selection is - or is that not information not available? Actually no, this needs some extensions to airportinfo() I think. Correct. We don't have that information available. bonus feature: a wind indicator arrow showing the wind direction and speed based on current environment. While that's useful for the current location, I don't think it's all that useful for airports elsewhere, which is a particular use-case for the dialog. If we could enhance the airportinfo() to include the actual METAR (or indeed expose a metar() call via Nasal), we could usefully display the current METAR for the selected airport, as well as show a wind arrow and the best-runway. I think I should go the full way here, and make a NasalMetar object that can be initialised as a location, and fires a Nasal callback when its data changes, i.e when it loads. We have all the pieces for this already, and glueing them together in this way would allow lots of interesting FMS and other features. I'll try to get that done in the next few days. James -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport selection feedback
Am 2012-09-20 11:30, schrieb James Turner: (Moving this discussion the the mailing list!) On 20 Sep 2012, at 10:24, Stuart Buchanan wrote: One thing I noticed is that the performance has taken quite a hit from adding the taxiways, as each taxiway segment is being drawn as a separate object. Thomas - any chance we could have a draw mode to allow a set of Quads to be defined? Right, don't forget we can build Canvas elements from C++ - we could have helper methods on the Nasal API which create a map layer automatically from an ICAO code. I may end up doing this for the route-path in the map widget, depending on performance. I don't think that Nasal is the bottleneck here, but I'll check it. I think that most time is spend with tessellation of the path but I'm also not sure about this one. Drawing multiple quads at once should be possible if putting all quads in a single path (Start a new subpath/quad use canvas.Path.moveTo() or canvas.Path.VG_MOVE_TO). I'll have a look if ShivaVG really creates just a list of quads and otherwise modify it to do so. If you need an aircraft symbol, eg. for showing the currently selected position have a look at my fgdata branch: https://gitorious.org/~tomprogs/fg/toms-fgdata/blobs/canvas/gui/dialogs/images/icon-aircraft.svg https://gitorious.org/~tomprogs/fg/toms-fgdata/blobs/canvas/gui/dialogs/map-canvas.xml#line234 It's looking really good, if we/I/Thomas could get panning and ideally smooth mouse-wheel zooming working, it would be fantastic. (And will make my life porting the MapWidget really easy) It's looking really good, if we/I/Thomas could get panning and ideally smooth mouse-wheel zooming working, it would be fantastic. (And will make my life porting the MapWidget really easy) That should be very easy to implement. I think I can do it the next days. Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport selection feedback
Am 2012-09-20 22:41, schrieb Stuart Buchanan: Unfortunately, that doesn't appear to handle overlapping quads very well: http://www.nanjika.co.uk/flightgear/taxis.jpg It is doing some XOR against the other layers? I'm sure I remember seeing this in a graphics textbook year ago... I've now changed the default fill rule from even-odd to non-zero. Should probably work better now... Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
