[FOSS-GPS] FoxtrotGPS paint-optimize branch

[John Stowers]

> > 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;

Cool, comments follow,

> - 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.

No callbacks is by design, the number of queued tiles is exposed as a
gobject property (tiles-queued). It can be polled at whatever frequency
the UI wishes (see python demo for example).

> - There seems to be no way to add/manage tile repositories programmatically.

Partially correct. There is no way to remove tile repositories
programatically but you are free to pass any string you wish as the
repo-uri property (see python demo for example)

> - I assume I can register event handlers on click events? Will it associate click events 
> with (groups of) images added to the widget?

There are two approaches here. If you want to manage clicks totally
yourself then just use the normal gtk+ click event API. If you wish to
manage clicks as though they are on a OSD element then you can do this
through the new layer API, at least to some degree. I have resisted
putting too much canvas capability into osm-gps-map.

> - Is there a way to control visibility of the overlays programmatically?

For custom overlays the implementation can control this, for the
provided overlay you can individually enable/disable the
zoom,center,d-pad etc elements. 

> - 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.

Yeah, I am carrying around a bit of backward compatibility cruft - this
falls into that category...

> - 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)

Partly as above. Images and layers serve a different purpose (layers =
overlays to use your term) so their API will not be entirely
symmetrical, although I really should add a remove_layer call.

The next signifigant API break I make (which will probbably be when
someone gives me enough reason) will be to clean up the track interface
so that there is no distinction between the first track (i.e. the
xxx_gps_xxx API) and a more general API for adding/removing/managing
multiple tracks.

> 
> 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.

I cant say I have observed such bugs, I will take your word (if gpxview
is using a recent version and correct build etc). Unfortunately I don't
have any maemo stuff to test with

Thanks a lot for the review,

John