[webkit-dev] forwarding headers and CMake
In my work getting CMake working on Windows, I discovered a subtle difference in how forwarding headers are made. In the existing build system, a forwarding header contains the entire contents of the original header. In the current CMake build, the WEBKIT_CREATE_FORWARDING_HEADERS macro creates lots of one line files that #include the original file. For example, my JSBase.h forwarding header contains only this one line: #include “JavaScriptCore/API/JSBase.h” In order to switch the Windows build over to use CMake, I’m pretty sure we would need the entire contents of the headers to be copied to the build directory. Would changing this build behavior cause a problem for the GTK or EFL ports? If so, I would probably make the forwarding headers macros port specific. Alex ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] border-radius lost when applying -webkit-filter
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
titleBasic CSS Filters/title
headBasic 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 951C++
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 1960C++
WebKitd.dll!WebCore::RenderLayerBacking::updateConfiguration()
Line 595 C++
WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
layer, WTF::VectorWebCore::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::VectorWebCore::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
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
titleBasic CSS Filters/title
headBasic 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 951C++
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 1960C++
WebKitd.dll!WebCore::RenderLayerBacking::updateConfiguration()
Line 595 C++
WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
layer, WTF::VectorWebCore::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::VectorWebCore::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
___
Re: [webkit-dev] forwarding headers and CMake
I think this might cause issues, because it requires the forwarding headers be regenerated when any of the target headers change. Why does Windows need this change? Are the headers being copied for some packaging purpose? If so, perhaps that can be a separate step specific to Windows. --Martin On Tue, Jul 28, 2015 at 6:03 PM, Alex Christensen achristen...@apple.com wrote: In my work getting CMake working on Windows, I discovered a subtle difference in how forwarding headers are made. In the existing build system, a forwarding header contains the entire contents of the original header. In the current CMake build, the WEBKIT_CREATE_FORWARDING_HEADERS macro creates lots of one line files that #include the original file. For example, my JSBase.h forwarding header contains only this one line: #include “JavaScriptCore/API/JSBase.h” In order to switch the Windows build over to use CMake, I’m pretty sure we would need the entire contents of the headers to be copied to the build directory. Would changing this build behavior cause a problem for the GTK or EFL ports? If so, I would probably make the forwarding headers macros port specific. Alex ___ 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] Infinite JavaScript loop blocks the MiniBrowser
Hello, I am trying to protect the MiniBrowser from executing faulty JavaScript code taking too much time / CPU. All browsers normally raise a pop-up allowing the user to stop the script and run away. But MiniBrowser does not seem to have such feature. It is just stuck forever ;-( After a little digging I found this JSC API: JSContextGroupSetExecutionTimeLimit() I had to implement a JSC Watchdog back-end because it is not implemented for EFL, fair enough - https://bugs.webkit.org/show_bug.cgi?id=147107 (ongoing) Now the JSContextGroupSetExecutionTimeLimit() have the expected behaviour. I can stop the JavaScript execution and run away... Great but the big problem now is that the JavaScript won't restart. Even while loading other pages, the JavaScript remains disabled. If you have any hints about this, I would be grateful. How to restart JavaScript execution? Where to look? Is it an EFL bug? Thanks, Pascal Jacquemart ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Infinite JavaScript loop blocks the MiniBrowser
Mark, do you know how to restart JavaScript after it has reached a watchdog time limit? Geoff On Jul 28, 2015, at 9:09 AM, Pascal Jacquemart p.jacquem...@samsung.com wrote: Hello, I am trying to protect the MiniBrowser from executing faulty JavaScript code taking too much time / CPU. All browsers normally raise a pop-up allowing the user to stop the script and run away. But MiniBrowser does not seem to have such feature. It is just stuck forever ;-( After a little digging I found this JSC API: JSContextGroupSetExecutionTimeLimit() I had to implement a JSC Watchdog back-end because it is not implemented for EFL, fair enough - https://bugs.webkit.org/show_bug.cgi?id=147107 https://bugs.webkit.org/show_bug.cgi?id=147107 (ongoing) Now the JSContextGroupSetExecutionTimeLimit() have the expected behaviour. I can stop the JavaScript execution and run away... Great but the big problem now is that the JavaScript won't restart. Even while loading other pages, the JavaScript remains disabled. If you have any hints about this, I would be grateful. How to restart JavaScript execution? Where to look? Is it an EFL bug? Thanks, Pascal Jacquemart ___ 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
