On Friday 14 May 2010 10:47:02 Sander van Grieken wrote: > On Friday 14 May 2010 01:15:39 John Stowers wrote: > > On Thu, 2010-05-13 at 14:21 +0200, Sander van Grieken wrote: > > > Hi All, > > > > > > Before the clash with Marcus Bauer and the forking of FoxtrotGPS I had > > > worked on > improving > > > the graphics routines. These improvements were coded against Tango 0.99.2 > > > and were > > > noticably faster on my freerunner, although some regressions were still > > > present. My > > > patches were never reviewed or merged, and instead Marcus implemented > > > another (more > crude > > > IMO) caching mechanism and released 0.99.3, from which FoxtrotGPS was > > > forked. So in > the > > > past weeks I have worked on rebasing my patches against the FoxtrotGPS > > > code base. > > > > Hi, > > > > This is just a friendly reminder to invite you all to check out > > osm-gps-map [1]. The optimisations you describe and many others were > > implemented in osm-gps-map a while ago. In fact, the excellent > > performance of osm-gps-map is one of the main reasons it is used in many > > of the most popular mapping apps on maemo. > > It sure looks very nice and I'd love to ditch my stuff and replace it with > osm-gps-map, > but there are some issues, AFAICS from the API; > > - There seems to be no callback for download-progress-reporting (number of > threads, queue > depth). I'd hate to ditch the visual download feedback foxtrot currently has. > - There seems to be no way to add/manage tile repositories programmatically. > - I assume I can register event handlers on click events? Will it associate > click events > with (groups of) images added to the widget? > - Is there a way to control visibility of the overlays programmatically? > - why are draw_gps and clear_gps exposed to the public API? They look like > paint > primitives, while the rest of the rendered objects are handled in a 'managed' > fashion. I > would have expected something like 'enable_draw_gps(boolean)' and > 'update_position' or > something. > - functions for managing tracks, images and layers are not symmetric; tracks > have no > remove function, layers have no remove function, images have no replace > function (which > would be nice for e.g. highlighting) > > From playing around a bit with gpxview on maemo, there seem to be some > glitches with > downloading tiles. Sometimes a whole zoom-level stays white, sometimes a > scaled tile > doesn't get updated with the tile from the correct zoom level.
Oh, and two more things: The widget seems to use alpha blending quite a lot. This probably won't fly well on the freerunner with its limited gfx bandwidth. Is there a way to toggle certain performance impacting settings? And finally, I think the tile downloading code should be externalized. A widget should not introduce a dependency on a http fetcher. Of course you can offer the current downloading code as an extra module which you can plug in, but the application should be allowed to replace that with its own downloader. So basically that would introduce a 'request_tile_url' callback, and a 'tile_ready' function to signal the availability of the new tile. grtz, Sander _______________________________________________ This message is sent to you from [email protected] mailing list. Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
