Re: drop-shadow filter vs. a separate property

On Jan 22, 2012, at 1:00 PM, Rik Cabanier wrote:

> 
> 
> On Sat, Jan 21, 2012 at 10:43 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> 
> On Jan 21, 2012, at 5:30 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> 
>> Hi Chris,
>> 
>> I agree that doing a drop shadow as a separate property makes sense.
>> I can't recall an example in Flash where a user needed to apply filters after doing a shadow. There are cases where artwork with a drop shadow comes into view with an alpha transition but in that case, the alpha filter can be applied before the drop shadow.
> 
> One of the early ideas for having a drop shadow in filters was to be able to shadow the background, border, border-image, contents, etc. individually or unioned in different combinations. 
> 
> I should think it would be useful to have the choice to apply a color filter either before or after drawing the shadow. For instance, I might have a whole page that is sepia-toned, including the shadows, and then have some other color effect when I hover over them, with the shadows losing their sepia tint and not being affected by the filter (or being affected by some filters and not others). Would that work if the shadow was not a filter?
> 
> Having sepia on the entire page including the shadows, would no longer work if drop shadow becomes a property. Of course, the user could calculate the sepia shadow color himself using the formula from the filters spec but this isn't as convenient.
> 
> If it's just the shadow that is losing its sepia tint, I'm not sure if this could be done either way (unless the user again calculates the sepia himself)

It's possible to do the drop-shadow before the filtering. That's what text-shadow and box-shadow do. Then all filtering operations would affect drop-shadow equally.

>  
> 
>> However, my fear is that this will create some push back from the WG's since it is yet another property that enters the CSS namespace. 
>> Also, the drop shadow property will be very similar to text-shadow which might lead to confusion...
> 
> I don't speak for the whole CSSWG, but I am not entirely opposed to it being a property. I just don't really understand how that would improve performance.
> 
> I'm not sure either. I've implemented drop shadows before using IPP and they were a one-pass operation.
> However, if you do the on a low end GPU, it might be a lot more complicated since you don't have a general purpose processor. I think doing them as the final step will avoid the compositing of the shadow with the source pixels. You would simple calculaty the shadow based on the source alpha and display it behind the original at the source position + shadow offset.
> Chris can correct me if I'm wrong...

Shadows can be done in one pass. They are essentially taking the alpha channel, turning it into rgb (using the shadow color), then blurring, offsetting and rendering it under the original image. That's all one pass, but 4 operations. Doing that embedded in a filter chain is harder than doing it separately, like we do with text-shadow and box-shadow today.

As far as the confusion with text-shadow goes, that's a good point. The issue really is about what is being shadowed. A text-shadow is added to the text after it is rendered. Drop-shadow would be added to the entire contents layer (including background) using the alpha channel as the shadow mask. So in that way they are doing different things. I think the confusion is manageable, but we do have to be careful about it.

> 
>  
> I had envisioned that some properties like that would just be syntactic sugar for what was still really a filter. Even text shadow would be sugar for a filter that filtered just content (not the box it is in, and somehow limited to only textual content), and then knocked out the original content shapes.
> 
> I agree. 
> In a couple of years (when hardware improves and all browsers support filters), this issue might just fix itself.
> Maybe Apple should just document for now that you have to do the drop shadow filter at the end if you use it on an iOS device.

And it seems to me that drop-shadow was added to the CSS Filter list because "it can be done as a series of filters". But that's true of many effects CSS does. The question is where does it properly belong in the pipeline. I think you can make a convincing argument that all the shadowing properties should be grouped in the same spot, i.e., as a rendering passes before filtering.

-----
~Chris
cmarrin@apple.com