<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Agreed, the merge/compositing step will be the major cost. Don't<br>you think a 99% transparency profile is a little unfair though, if GD
<br>(as you suggest) fast-paths the cases where the source image's pixel is<br>0% or 100% opaque? Even with antialiasing-happy AGG, I think the 0% or<br>100% opacity case will be overwhelmingly common for all but line layers.
<br> I suggest then, that compositing will not be as costly as it was in<br>your 99%-opacity profile. To test the typical likelihood & effect of<br>"free" pixel compositing, we'd need to hack msDrawMap(), unless you can
<br>think of an easier way?</blockquote><div><br>Dave, <br></div><br></div>I tried this out on line layers, which in effect means that a very vast majority of the <br>pixels were fully transparent , i.e. a "free" compositing operation (check for 0 opacity
<br>and move on to the next pixel). Even in that case, most of the time was just spent on <br>iterating over the layer pixels, not the actual blending operations, so I would tend to <br>say that this wasn't a worse case scenario, on the contrary.
<br><br>cheers,<br>tb<br><br>