Parallelizing calls to msDrawLayer()

[thomas bonfort]

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
seperately
- 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.

tb

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?
>
> Thanks,
>
> Dave Fuhry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20071013/a9c0605e/attachment.html