This works for me using the latest ToT build. I would recommend updating your
source tree.
--Myles
> On Jul 28, 2015, at 4:52 PM, Vienneau, Christopher <cvienn...@ea.com> wrote:
>
> Hi,
>
> I’m on a slightly older pull from WebKit trunk (179714) and I’m seeing this
> issue where border radius is lost if a css filter is also applied. My sample
> page looks like this:
> <!DOCTYPE html>
>
> <html>
> <title>Basic CSS Filters</title>
> <head>Basic CSS Filters</head>
>
> <style>
> #pic {
> border-radius: 10px;
> -webkit-filter: sepia(0.8);
> }
> </style>
>
> <body>
> <div>
> <img id="pic" src="testImage.jpg">
> </div>
> </body>
> </html>
>
> When I run with the above code the image is rendered with the Sepi filter,
> but the border radius is not applied. If I comment out the filter the image
> is properly rendered with the border radius applied. By debugging I can see
> that a different code path is followed in the two cases.
> Without the filter:
> > WebKitd.dll!WebCore::GraphicsContext::clip(const WebCore::Path
> > & path, WebCore::WindRule windRule) Line 951 C++
> WebKitd.dll!WebCore::GraphicsContext::clipRoundedRect(const
> WebCore::FloatRoundedRect & rect) Line 586 C++
>
> WebKitd.dll!WebCore::RenderBoxModelObject::clipRoundedInnerRect(WebCore::GraphicsContext
> * context, const WebCore::FloatRect & rect, const WebCore::FloatRoundedRect
> & clipRect) Line 540 C++
> WebKitd.dll!WebCore::RenderReplaced::paint(WebCore::PaintInfo
> & paintInfo, const WebCore::LayoutPoint & paintOffset) Line 180 C++
> …
> we get into clipRoundedInnerRect which goes into the code which can perform
> the clipping operation, and all works as expected.
>
> With the Filter (3 callstacks below):
> >
> > WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const
> > WebCore::FloatRoundedRect & roundedRect) Line 377 C++
> WebKitd.dll!WebCore::RenderLayerBacking::updateImageContents()
> Line 1960 C++
> WebKitd.dll!WebCore::RenderLayerBacking::updateConfiguration()
> Line 595 C++
>
> WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
> & layer, WTF::Vector<WebCore::GraphicsLayer *,0,WTF::CrashOnOverflow> &
> childLayersOfEnclosingLayer, int depth) Line 1522 C++
> …
>
> >
> > WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const
> > WebCore::FloatRoundedRect & roundedRect) Line 377 C++
> WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect()
> Line 1124 C++
>
> WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003
> C++
>
> WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
> & layer, WTF::Vector<WebCore::GraphicsLayer *,0,WTF::CrashOnOverflow> &
> childLayersOfEnclosingLayer, int depth) Line 1609 C++
> …
> >
> > WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const
> > WebCore::FloatRoundedRect & roundedRect) Line 377 C++
> WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect()
> Line 1124 C++
>
> WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003
> C++
>
> WebKitd.dll!WebCore::RenderLayerCompositor::updateCompositingDescendantGeometry(WebCore::RenderLayer
> & compositingAncestor, WebCore::RenderLayer & layer, bool
> compositedChildrenOnly) Line 1862 C++
> …
>
> In this path we never call clipRoundedInnerRect, we do however call
> setContentsClippingRect with what looks like appropriate parameters to do
> what we would want. However upon investigation it appears that this data is
> not used by anything. Looking at other ports it seems that
> GraphicsLayerCA.cpp may be making use of this data in its clipping technique.
>
> Looking for fixes that might already be available I found the two below
> interesting, however note that I already have these in the change that we
> last took. They just sounds extremely similar to what I’m describing.
> http://trac.webkit.org/changeset/179147
> <http://trac.webkit.org/changeset/179147>
> http://trac.webkit.org/changeset/175794
> <http://trac.webkit.org/changeset/175794>
>
>
> I’m wondering if it can be confirmed that this issue has been a problem for
> other ports as well? Are there any fixes that address my problem that I may
> have overlooked? What if anything needs to be done to support this (is
> something like what is done in the CA port a requirement?) Any advice on
> implementing the minimal changes, CA’s changes appear extensive.
>
> Thanks for any advice
>
> Chris Vienneau
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
