Parallelizing calls to msDrawLayer()

thomas bonfort thomas.bonfort at GMAIL.COM
Sat Oct 13 03:45:28 EDT 2007

interresting idea...
the problem with this approach is that parralelizing the rendering is far
from being
a "free" operation:
- memory-wise, you have to allocate n-layers images to render each of them
- computationnaly wise, you have n-layers full image blending operations,
which is far
from being a light operation.

I've profiled the rendering of a 7 layer map setting each layer to 99%
opacity, which currently
means that the layer is rendered on a temp image and blended onto the map
image for each
layer ( this roughly simulates the operations that would happen if using
your approach,
except that we don't get some of the "free" blended pixels, i.e. pixels
whose opacity is 100%
and therefore are just replaced in the final image instead of composited ).
the result is that
50% of computing time is spent on the blending operations.

seeing this, we'd have to make sure that this non negligeable processing
supplement is
compensated by the overhead 'won' when doing the i/o for each layer.


On 10/12/07, David Fuhry <dfuhry at> wrote:
> Has anyone looked into parallelizing the calls to msDraw[Query]Layer()
> in msDrawMap()?
> Although I'm new to the codebase, it seems that near the top of
> msDrawMap(), we could launch a thread for each (non-WMS/WFS) layer,
> rendering the layer's output onto its own imageObj.  Then where we now
> call msDraw[Query]Layer, wait for thread i to complete, and compose that
> layer's imageObj onto the map's imageObj.
> In msDraw[Query]Layer(), critical sections of the mapObj (adding labels
> to the label cache, for instance) would need to be protected by a mutex.
> A threaded approach would let some layers get drawn while others are
> waiting on I/O or for query results, instead of the current serial
> approach where each layer is drawn in turn.  Multiprocessor machines
> could schedule the threads across all of their cores for simultaneous
> layer rendering.
> It seems this could significantly speed up common-case rendering,
> especially on big machines, for very little overhead.  Has there been
> previous work in this area, or are any major drawbacks evident?
> Thanks,
> Dave Fuhry
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the mapserver-dev mailing list