I'll see if I can reproduce this using our Apple Windows port, which also uses 
GraphicsLayerCA, though one based on  Windows graphics primitives.

The WinCairo compositor is based on the OpenGL ES backend, via the ANGLE 
library. Alex Christensen knows more about how that works.

Thanks,

-Brent

Sent from my iPad

> On Jul 30, 2015, at 2:26 PM, Myles C. Maxfield <mmaxfi...@apple.com> wrote:
> 
> I'm testing on the Mac OS X port, which uses GraphicsLayerCA.
> 
> Sounds like a bug with whichever compositor the win-cairo port is using, 
> which I am not familiar with.
> 
> --Myles
>> On Jul 29, 2015, at 10:24 AM, Vienneau, Christopher <cvienn...@ea.com> wrote:
>> 
>> Thanks Myles,
>>  
>> Before I go through the effort of re-integrating, a few questions about your 
>> test:
>>  
>> Which port are you testing on? I had been able to repro in our demo and the 
>> win-cairo demo (both using the 179714 build). 
>> Are you are using the GraphicsLayerCA as I mentioned below? If so regardless 
>> that your version is newer than mine, it *might* be why it’s working.
>>  
>> Chris
>>  
>> From: Myles C. Maxfield [mailto:mmaxfi...@apple.com] 
>> Sent: Tuesday, July 28, 2015 5:36 PM
>> To: Vienneau, Christopher
>> Cc: Webkit Development List
>> Subject: Re: [webkit-dev] border-radius lost when applying -webkit-filter
>>  
>> 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/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
>> 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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to