[FOSS-GPS] FoxtrotGPS paint-optimize branch

[Sander van Grieken]

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