On May 27, 12:22 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > On May 27, 12:09 pm, "L. David Baron" <[EMAIL PROTECTED]> wrote: > > > I can see shadows being quite strange for 'continuous', but I don't > > see how they make a case for 'bounding-box' vs. 'each-box'. > > You don't want each box to have independent overlapping shadows. > > It should work like 'opacity', where the boxes for an element are > rendered as a group, then we do the filter effects.
Unfortunately this turns out to create a rather nasty reflow problem (although it may be Gecko-specific). Suppose we apply a filter to an inline element with two frames. The filter could fill its filter region, which could be any size relative to the objectBoundingBox or in userSpaceOnUse units. In particular, it could be arbitrarily larger than the objectBoundingBox. Exactly how those units are interpreted for inline frames is something that we need to hammer out a spec for (I have stuff in my tree which I'll talk about later), but it doesn't matter for this discussion. The problem is, it's not clear how to allocate "excess" area drawn by a filter for a group of frames to the overflow areas of individual frames. I think the only reasonable solution is to assign the filter's area to the overflow area of the *last* continuation, because that's the only frame where we can be sure that all the prev-in-flows have been reflowed. The problem is, when nsFrame::FinishAndStoreOverflow is called, we haven't placed the frame yet so we can't compute the bounding-box of all the continuations properly. I think the only way to fix this is to do some fairly major changes to overflow area management. Changes that we want to do anyway to handle tricky stuff like multi-continuation, relatively-positioned frames with abs-pos children that use "bottom", and so that we can adjust overflow areas without reflow, and so that we can split the "overflow area" concept up into "union of border-boxes of frame subtree modulo clipping" from "area drawn to by a frame subtree". For now, I think I'll just hack it so that overflow areas for each filtered frame are computed as if that frame alone was the subject of the filter. That will work for a lot of common cases, including all cases where the filter does only per-pixel processing and when there is only one frame for a filtered element. Rob _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
