Parallelizing calls to msDrawLayer()
thomas.bonfort at GMAIL.COM
Mon Oct 15 05:34:02 EDT 2007
> 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?
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mapserver-dev