[FOSS-GPS] FoxtrotGPS paint-optimize branch

[John Stowers]

> > 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).
> 
> Well I actually meant signals instead of callbacks, but fair enough, this should suffice. 
> Is it also possible to inspect currently running download threads, and is there a way to 
> cancel the queue?

No, those things are not exposed in the API yet. It would be easy to add
though.

> 
> > > - 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...
> 
> Ok. Is it sufficient to only call draw_gps when the position gets updated or are there 
> more situations where I need to (re)draw?

You only need to call draw_gps when a new point comes in (it adds a new
point to an internal track, the 'gps track' that gets the marker drawn
at its head)

> 
> > > - 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.
> 
> Yeah after looking at the code I will probably not use layers to render friends, photo's 
> etc, but instead use the image functions..

I agree.

> 
> > 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.
> 
> Tracks can get quite large. Is the entire track redrawn when calling replace_track, or 
> does it do a comparison and only draw the new segments of the track?

If you call replace_track the whole lot will get redrawn. The only track
that is treated specially is the 'gps track' so calling draw_gps to add
a new point only draws the new segment.

John