transparency at the STYLE level

No, transparency should be at the STYLE level, which is the closest to SLD's
Symbolizers.

You're absolutely right Sean, I have changed the bug summary accordingly.

Support at style level will likely be expensive, is it really necessary? Would 
feature level transparency be good enough? That is, moving transparency from 
msDrawMap to msDrawShape. Even then it may slow things down a good bit.

Steve

My purpose as a user would be to get a whole layer of polygons transparent using
SLD.

SLD specifies transparency at the Symbolizer level, so users could theoretically
request maps which have different transparency for different styles, but I think
this will rather be exception then rule.

Just my opinion though.

One place you might want transparency at CLASS level (or lower) is to have 
transparent polygons in one class and opaque polygons in another class, or 
to do a classification that has continuously varying transparency.

Also, now, if you want to have a polygon with a transparent fill and solid (100%
opaque boundary) you need two layers -- at double the cost.  With transparency 
in a style, you could have a solid stroke style and a transparent fill style.

I'm not sure which is faster/slower: two iterations over a layer for separate
stroke/fill opacity or a few extra statements within msDrawShape.

To be exactly consistent with the SLD, we need to have the transparency at the
STYLE level as decribed by Sean's comments. 
 
 Steve : I understand the cost associated with doing tranceparency at style
level, but Is it correct to assume that if no transparency is set (which is the
general case), the user won't see any diffrence ?  If that is the case, those
who needs it should be prepared to pay the price for this feature.
 Steve : do you intend to keep the transparency at the layer level as well as
adding it at a class (or style) level ?  

Setting target to future.

AGG support for style level opacity has been added in r7476, for all symbol types *except* PIXMAP symbols.

known issue: rendering lineworks with multiple styles (eg to create outlined roads) will produce unwanted results (intersections appear at (more or less)twice the desired opacity, and the caching of the bottommost style is ineffective). see attached image for an example.

style level opacity rendering glitches on multi-style lineworks

Thomas has addressed this in the AGG code for 5.2 so I'm going to close this in favor of tracking specific to that work should it be necessary.

Steve