Re: drop-shadow filter vs. a separate property

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)


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

>

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

Rik


>
> On Fri, Jan 20, 2012 at 10:57 AM, Chris Marrin <cmarrin@apple.com> wrote:
>
>>
>> On Jan 20, 2012, at 10:48 AM, Dirk Schulze wrote:
>>
>> > First sorry for the double post. The first message was not delivered,
>> or at least with a very big delay of two days :P.
>> >
>> >
>> > On Jan 20, 2012, at 10:44 AM, Chris Marrin wrote:
>> >
>> >>
>> >> On Jan 18, 2012, at 2:41 PM, Dirk Schulze wrote:
>> >>
>> >>> If we would not allow drop-shadow in the filter chain, developers
>> will just surround the content with the filter by a new div and apply the
>> filter there. The situation gets worst if drop-shadow would be in the
>> middle of the filter chain. User would have to surround the filtered
>> content  with two div's and apply three different filters. I assume that it
>> is better to deal with it in the implementation. Even eliminating
>> drop-shadow would rarely make the situation better.
>> >>
>> >> You're saying that a developer would do that if they need a
>> drop-shadow embedded between other filters, which is true. I'm saying that
>> I don't think this would be a common case at all, if it ever made sense.
>> And in the cases where a developer felt the need to do it, then a sandwich
>> of elements would not be an unreasonable solution.
>> >>
>> >> And my bigger point is that it seems like drop-shadow is more akin to
>> text-shadow and box-shadow than to filters. So why not treat it the same?
>> > I agree, see my previous posting:
>> >
>> > "I have nothing against adding a new CSS property. WebKit already has
>> an experimental drop shadow property for SVG (-webkit-svg-shadow). But it
>> is a different approach to add a new property to make it easier for web
>> developers to access a feature or to add it because of performance
>> concerns. The performance concern won't disappear with a new property."
>>
>> That's true (and sorry for missing your original post). There are really
>> two reasons I bring this up. In starting to implement the hardware
>> acceleration path, I encountered problems embedding drop-shadow into a
>> hardware filter chain. It's much more complex than the others and so it
>> added complications. These complications can certainly be solved with some
>> amount of pain, which is fine. But that got me thinking about the sense of
>> having drop-shadow in CSS Filters at all. Given that text-shadow and
>> box-shadow were separate properties, it seemed that maybe drop-shadow
>> should be, too.
>>
>> So I think it makes sense from a spec standpoint to get rid of the
>> drop-shadow filter and add it as a separate property. And it's a nice side
>> effect that adding drop-shadow as a separate pass from the filters makes
>> our implementation simpler.
>>
>> -----
>> ~Chris
>> cmarrin@apple.com
>>
>>
>>
>>
>>
>>
>