Re: drop-shadow filter vs. a separate property

On Mon, Jan 23, 2012 at 10:18 AM, Chris Marrin <cmarrin@apple.com> wrote:

>
> 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.
>

I forgot that the properties are applied before filtering. This makes drop
shadow as a property less interesting since you likely want to filter the
source and then apply a drop shadow to it.
Applying effects on the shadow's color and shape are not as common...

Why not optimize (or only implement) the case where a shadow is at the end
of the filter chain and make it accelerated when the technology catches up?

Rik