Parallelizing calls to msDrawLayer()

[thomas bonfort]

>     Agreed, the merge/compositing step will be the major cost.  Don't
> you think a 99% transparency profile is a little unfair though, if GD
> (as you suggest) fast-paths the cases where the source image's pixel is
> 0% or 100% opaque?  Even with antialiasing-happy AGG, I think the 0% or
> 100% opacity case will be overwhelmingly common for all but line layers.
>   I suggest then, that compositing will not be as costly as it was in
> your 99%-opacity profile.  To test the typical likelihood & effect of
> "free" pixel compositing, we'd need to hack msDrawMap(), unless you can
> think of an easier way?


Dave,

I tried this out on line layers, which in effect means that a very vast
majority of the
pixels were fully transparent , i.e. a "free" compositing operation (check
for 0 opacity
and move on to the next pixel). Even in that case, most of the time was just
spent on
iterating over the layer pixels, not the actual blending operations, so I
would tend to
say that this wasn't a worse case scenario, on the contrary.

cheers,
tb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20071015/ee4d4956/attachment.html