Hi,
Below is an e-mail I sent to webkit-dev the other day. I just wanted to check
with users of GTK if you've noticed the same problem in past or current version
of your port. The problem can be easily reproduced with the sample html below.
Is the image rendered with both the sepia filter and the border-radius?
Does your port make use of TextureMapper? "WebCore\platform\graphics\texmap"?
Does your port use GraphicsLayerCA?
Thanks for your help
Chris Vienneau
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/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-gtk mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-gtk
