Parallelizing calls to msDrawLayer()
thomas.bonfort at GMAIL.COM
Sat Oct 13 03:45:28 EDT 2007
the problem with this approach is that parralelizing the rendering is far
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
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
compensated by the overhead 'won' when doing the i/o for each layer.
On 10/12/07, David Fuhry <dfuhry at cs.kent.edu> 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?
> Dave Fuhry
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mapserver-dev