2nd)
I implemented two ImageTraverser using different load balancing strategy: the first using the WorkQueue approach (with granularity=5), the latter using a trivial static scheduling of packet between threads.

I also tested these two balancer on 3 complex scenes (from 200 000 to 8 000 000 of primary rays + reflections).

The test platform is an Intel Core 2 Quad Q6600 (4 cores).
Surprisingly scalability is higher with the static approach...

am I using the WorkQueue in the wrong way? Which is the better load balancer available in Manta for my target platform?

The better load balancing approach is probably more dependent on the graphics workload than on the hardware platform.  The rendering cost can be visualized by pressing 't' and then using 't+ctrl' or 't+shift' to adjust the color map. How does changing granularity effect scalability?

I also noted that the scalability is fine with low fps (close to 4x), but it slow down for higher fps (3x).

What are the actual refresh rates for low and high? Also what changes to produce the lower or higher frame rate, i.e. does the scene become more complicated, the output resolution greater etc.?

I wonder if this is due to a relatively higher cost of the barrier synch.

The barriers only become expensive if there is another source of load imbalance in the pipeline which the load balancer is unable to compensate for, e.g. the animation callbacks occur in a separate section of the control loop from rendering, so if one thread executes a very expensive animation update, the other threads might end up idling at the barrier which would hurt scalability. This type of load imbalance is usually visible in a profiler.

Abe