[FOSS-GPS] FoxtrotGPS paint-optimize branch

[Sander van Grieken]

On Friday 14 May 2010 14:09:27 John Stowers wrote:
> 
> > 
> > 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?
> 
> There is currently no way to toggle such optimizations. I would want to
> see some sort of benchmark to suggest that the alpha component of the
> drawing is causing some measurable slowdown before considering this.

It's only when the HDOP circle gets very big that a big area is alpha-blended, so probably 
not interesting right now to look into it. In normal use this will have little impact.

So, never mind :)

> > 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.
> 
> I'm not a fan of this idea sorry. IMO osm-gps-map should be 
>  * "batteries included"

Well it should not be taken out, but the possibility of overriding it sounds interesting, 
although for foxtrot I'll take the built-in downloader.

>  * a good GObject/Gtk+ citizen

Hmm I don't know exactly what that means, I'm more of a ObjectOriented/C++ kind of guy, 
where 'separation of concerns' is one of the important axioms.

Besides, there was talk on this list about a tile provider library, which would rhyme with 
this separation.

So my point basically is, you can have batteries included without discarding the concept 
of separation of concerns.

grtz,
Sander