Re: [css3-background] vastly different takes on "blur"

To get a better handle on counting the pixels, and seeing what browsers do, and what a human can perceive, I created a little experiment, that you can view here:

http://www.bradclicks.com/cssplay/small-shadow-blurs.html

I noticed that it was pretty hard to see the very lightest pixels, and in the dark areas there were even more shades that I could not perceive. So I colorized the results like a night vision scope to improve that. 

The renderings are based on a Webkit nightly from Apple, on the Mac, but it looks like Firefox does the same. Some observations as I worked on this:

• It seems that having an odd number of pixels for the total width of the blend is not possible, and floats are rounded down (I think). Is this a Gaussian blur limitation, or something else?

• Shadows can be any color, including white, so I can't really recommend that we clip the range based on a per-color perception of whether or not a pixel is distinguishable from totally opaque or totally transparent. But it does seem like 3% black is almost indistinguishable from white, and that 97% black (or green-black in my experiment) is almost indistinguishable from total black, so maybe there should be limits in that range for fitting the transition to the space. Simon mentioned that implementations already clip the infinite edge of the Gaussian blur at some imperceptible point. 

• I would not want an implementation to use a blur algorithm where each pixel was 1/10 the opacity of the pixel next to it, but the current definition does not disallow that. If we limit the transition to be in, e.g. the 3% - 97% range, then perhaps we can thereby mitigate some of the more ridiculous blur algorithms.  

• I really want the definition to be results-based, as it is in the LCWD, and not something based on a recipe such as "insert a number in to a black box whose workings is not well-understood by ordinary people, and accept whatever rendering comes out of it." Even if that is how canvas defines it. 

• If this is what 'text-shadow' does (there seems to be some debate about that still), and if odd numbers are really not possible, then I think I will join the enemy camp about measuring outward distances instead of total blend width. But it really has nothing to do with the arguments I heard prior to the one about text-shadow (which I thought were just plain silly). But I still want something predictable, even if it means slight adjustments to the definitions of both box-shadow and text-shadow.




On Jun 23, 2010, at 11:17 AM, Tab Atkins Jr. wrote:

> On Wed, Jun 23, 2010 at 11:16 AM, Brendan Kenny <bckenny@gmail.com> wrote:
>> On Wed, Jun 23, 2010 at 1:14 PM, Brendan Kenny <bckenny@gmail.com> wrote:
>>> Just to be clear, aren't the mockups for each option going to be the
>>> same thing? For instance, wouldn't Simon's example
>>> 
>>> http://smfr.org/misc/shadow.html
>>> 
>>> just be accompanied by the question
>>> 
>>> "Would you describe this as 'blur: 8px' or 'blur: 16px'?"
>>> 
>>> ?
>> 
>> or, as a better example
>> http://smfr.org/misc/shadow-webkit.png
>> so browser differences don't confuse things.
>> 
> 
> Indeed, PNGs are necessary, since in Chrome I'm seeing that as
> something that could be described as either 4px or 8px, not 8px or
> 16px.
> 
> ~TJ

Received on Friday, 25 June 2010 16:52:18 UTC