<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&nbsp;&nbsp;&nbsp; Agreed, the merge/compositing step will be the major cost.&nbsp;&nbsp;Don&#39;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&#39;s pixel is<br>0% or 100% opaque?&nbsp;&nbsp;Even with antialiasing-happy AGG, I think the 0% or<br>100% opacity case will be overwhelmingly common for all but line layers.
<br>&nbsp;&nbsp;I suggest then, that compositing will not be as costly as it was in<br>your 99%-opacity profile.&nbsp;&nbsp;To test the typical likelihood &amp; effect of<br>&quot;free&quot; pixel compositing, we&#39;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 &quot;free&quot; 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&#39;t a worse case scenario, on the contrary.
<br><br>cheers,<br>tb<br><br>