W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: box-shadow offset when transform:rotate is used

From: Christian Mayer <mail@ChristianMayer.de>
Date: Fri, 19 Feb 2016 23:54:19 +0100
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
Message-ID: <56C79D1B.2070304@ChristianMayer.de>
Am 19.02.2016 um 17:52 schrieb Simon Fraser:
> Painting shadows post-transfsrms is hard. You’d have to move shadow
> rendering into the compositor,
> which would mean doing a mask/blur operation on every frame of animation
> for animated, shadowed things.
> I doubt that implementors want to go there.

Interesting point.

But I see a different implementation possibility which is nearly as good:
You could apply a different transformation matrix to the shadow, one
respecting the offset in screen coordinates. And then still paint the
shadow at the same step of the pipeline as it is right now.

The calculations for that are simple (worst case: a matrix
multiplication; more likely: two additions).

The "nearly as good" comes from a small drawback: this will only work
"perfect" with translation, rotation and perhaps uniform scale.
"Perfect" means that the blur radius and spread distance parameters will
still be in the object coordinate system and not in the screen
coordinate system.

<div style="box-shadow: TheNewKeywordLikeScreen 10px 10px 5px #000;

This would have in the "nearly as good" definition a blur width of 10px
and a blur height of 5px (and not a width and height of 5px).

But I guess this limitation is very small.

The specification itself would then only say that the first two
dimensions (the offsets) of the shadow property are applied in screen
space and not in object space.
(The original request would have applied the transform also to the blur
radius and spread distance parameters).

The rendering could work then like that:
1) calculate the transformation matrix of the element
2) add the shadow-offset and draw the element as it's shadow (exactly
   like already implemented, except of the two additions)
3) draw the element (w/o the added offset, of course)
4) use all of that in the compositor as already implemented

Received on Friday, 19 February 2016 22:54:49 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:57 UTC