Le coin à Guij

As Olivier was saying:

Hope to see you there!

Here are two things I found quite useful recently with vim:

• GOBgen, which I’ve used intensively while writing the code skeleton of PAF (which is now about complete). It’s not perfect, I always find myself tweaking the content it created, but it’s still a lot faster than doing everything by hand.
• A small tweak to the quickfix stuff (you know, :make & co). I was annoyed by libtool executions often being interpreted as error output by vim. The problem is that a call to libtool with a -version-info 0:0:0 or something like that is often made by make, when using libtool (at least in the way it is set-up for pigment and PAF). That thing with numbers and columns looks too much like an error or warning from gcc for vim, and each time it is called, it is interpreted as an error that makes vim To tell it to calm down, I’ve created a gcc.vim file ~/.vim/after/compiler/ that contains the following:
  
let &errorformat .= ',\%+G-version-info\ %*\\d:'

  This tells vim that anything with “-version-info [number]:” is a general message, and not an error or warning. To ensure this is used, I have the following line in my ~/.vimrc:
  
au FileType c compiler gcc

  Note that you could also achieve a similar result by setting the g:compiler_gcc_ignore_unmatched_lines variable, but then you might miss real errors that don’t point to a specific file (like some linking errors) as I understand it.

I was wondering about this issue for PAF. I want to provide facilities to animate GObject properties, but is this something sensible? In the case of an interactive GUI, can we think of updating a hundred properties for each frame?

To answer these questions, I have written some code, that would do as many g_object_set()/g_object_get() as you want, and measure how much CPU time it takes. The code is available as a bzr branch at http://emont.org/property-tests/, look in the gobject directory (I have also written a similar code in python, and in “simple C” with nested structures).

The result of this, on my laptop (a Pentium M 1.86 GHz) is the following:

$ ./gobject/test 1000000
n=1000000
stress_set(): 1.440000
stress_get(): 0.480000
stress_get_set(): 1.940000
$

Here I ask for a million of sets, then a million of gets, then a million of couples get,set (to increment my float property by 0.1 at each iteration).

So, we can say that on my machine, a g_object_set() takes about 1.5 µs. Now, if we want to animate simultaneously a hundred properties, meaning that we want to update them all at each frame, we will spend 150µs just for g_object_set().
Let’s consider we have a 60 Hz screen, that means we have a total time of 16.667 ms, or 16,667 µs, and that in that case, we will spend about 1% of our time updating properties; I want to say that’s something that can be afforded in most cases. On modern embedded device, I guess we can expect the CPU to be up to 5 times slower, so in this case, that would be more like 5% of our time spent on updating GObject properties. That might be more of an issue, especially since CPU usage means energy consumption.

A question that remains open is Could g_object_set() be more efficient?

To be frank, I don’t really know, but I have made a similar test with python:

$ python python/test.py 1000000
n= 1000000
stress_set(): 0.29
stress_get(): 0.14
stress_get_set(): 0.34
$


I would tend to consider that the object system of python provides a similar set of functionality, but here, we’re speaking of 0.3µs (about 5 times faster than GObject), so, yeah, I guess there is room for improvement in g_object_set(), but it is yet to be decided if it is worth it…

Yet, it is a certain thing that the price is cheap enough for animations on the desktop, and for that reason it makes sense to put GObject propertiy animation facilities in PAF, and to add GObject properties to Pigment or Clutter at some point, since it would tend to make the programming (and creation of language bindings) of these things much easier.

Haven’t been too active on PAF lately, but I’m coming back to it. I will try to have a satisfactory API this week, and then continue writing the code skeleton and doc, which I have started a bit (for stuff I don’t think I will change much in the API).

Also, I have put stuff in place to ease the job, and to ease collaboration (yes YOU are invited to participate), more specifically the following:

• a launchpad project
• a wiki page

I am quite happy with most of PafClock and PafAnimation. I think PafImplicitAnimator needs a bit more reflection, and I don’t like that much the name of PafModifier. If you don’t understand what all these objects are, please have a look at the wiki page, get the branch (bzr branch lp:paf) and have a look at misc/paf.xmi (UML file, readable at least with umbrello) and examples/poc.c (examples of how the library could be used).