Time for a libjana-based gnome clock applet?

Just read Federico's post about how intlclock draws its map and calculates the sunlight time. That's a pretty incredible amount of overkill! Maybe they should look at the code in the JanaGtkWorldMap widget, that I personally think looks at least as nice :)

JanaGtkWorldMap draws directly with cairo calls, using data from sunclock (the format of which is derived from xearth, apparently) - one linear gradient for the sea, filled polygons for the land mass shadows, then an extra set of filled polygons on top of that. The sunlight curve is a simple curve equation, rather than ray-tracing (which probably isn't quite as accurate, no, but at this level it really doesn't matter), components of which are cached on initialisation. Drawing happens in a (interruptable) thread so the widget never blocks for any significant amount of time, and after drawing once, the result is stored to a back-buffer.

On top of this, as the widget changes size, it does adaptive LOD to reduce the amount of points being drawn. The widget has an option to render at a static size and scale that rendering instead of re-rendering when the size changes. It also has API to put custom markers on top of the map and widgets can be packed inside it. Drawing code could easily be replaced by gdk calls to boost speed (and I may well do this, cairo is slow :(). I'd like to think the API is easy to use too... Any takers?

Mathias Hasselmann says:

Of course cairo is slow - the way you use it: You seem to render to a image surface, instead of rendering to a X11 surface created with cairo_image_surface_create. This is know to be slow and this has to be slow, as all drawing operations are done by the CPU in memory.

Mathias Hasselmann says:

Ok, instrumented the code of JanaGtkWorldMap and JanaGtkClock. Seems to reduce rendering time by 50% - but, they weren't slow anyway:

  draw_map: 0.04s
  draw_clock: 0.01s
  jana_gtk_world_map_expose_event: 0.0005s
  jana_gtk_clock_expose_event: 0.0001

Seems more like some bad interaction between gtk's double buffering and your drawing code. Dunno: It's late. Will continue to look tomorow.

Chris Lord says:

@Mathias: Thanks for looking, I appreciate it :) This is really the first real bit of cairo coding I've done, so apologies if it's terrible - Don't you lose alpha with an X11 surface? If not, I guess I've been rather silly!

LionsPhil says:

Ouch. No kidding on the overkill; I bet that guassian blur is particularly bad bang for your cycles.

Any comments?