Initialize document dimensions at beginning of replay #3
Labels
Comments
ghost
assigned 
burg
pushed a commit
that referenced
this issue
Oct 27, 2012
https://bugs.webkit.org/show_bug.cgi?id=99899 Reviewed by Ryosuke Niwa. We cannot provide an elegant way to measure the memory consumption of the PageLoad tests, but we can turn them into simple performance tests and measure their memory footprint and performance that way. This change moves and renames the related files to their new location and adds html/js wrappers for them. This is the #3 commit of the whole patch. * PageLoad/svg/files/42470-flower_from_my_garden_v2.svg: Removed. * PageLoad/svg/files/44057-drops on a blade.svg: Removed. * PageLoad/svg/files/deb9frac1.svg: Removed. * PageLoad/svg/files/food_leif_lodahl_01.svg: Removed. * SVG/Debian.html: Added. * SVG/DropsOnABlade.html: Added. * SVG/FlowerFromMyGarden.html: Added. * SVG/FoodLeifLodahl.html: Added. * SVG/resources/Debian.svg: Copied from PerformanceTests/PageLoad/svg/files/deb9frac1.svg. * SVG/resources/DropsOnABlade.svg: Copied from PerformanceTests/PageLoad/svg/files/44057-drops%20on%20a%20blade.svg. * SVG/resources/FlowerFromMyGarden.svg: Copied from PerformanceTests/PageLoad/svg/files/42470-flower_from_my_garden_v2.svg. * SVG/resources/FoodLeifLodahl.svg: Copied from PerformanceTests/PageLoad/svg/files/food_leif_lodahl_01.svg. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@132531 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Feb 14, 2013
https://bugs.webkit.org/show_bug.cgi?id=73926 This patch fixes a shutdown race condition in CCLayerTreeHostTest which may happen if endTest() is called from within the drawLayersOnCCThread() test hook. The sequence of events leading to the problem is: 1. CCThreadProxy::scheduledActionDrawAndSwap() is called when a frame begins. 2. CCThreadProxy calls drawLayersOnCCThread(), which in turn calls endTest(). 3. Seeing it's not running in the main thread, endTest() posts a task calling itself in the main thread. 4. CCThreadProxy posts a task for calling didCommitAndDrawFrame() in the main thread. The race is between the task posted in step #3 and the CC thread running in scheduledActionDrawAndSwap(). If the endTask() task is scheduled before the CC thread reaches step #4, it drains the pending message queue (CCLayerTreeHostTest.cpp:369) before the task in step #4 is posted. The result is that the didCommitAndDrawFrame() task is executed after the test fixture has been torn down, causing a read of unallocated memory in CCScopedThreadProxy::runTaskIfNotShutdown (as m_targetThread is no longer valid). The fix is check m_shutdown before touching m_targetThread in CCScopedThreadProxy. That is, events will still be queued after shutdown but they will not be processed. Patch by Sami Kyostila <skyostil@chromium.org> on 2011-12-14 Reviewed by James Robinson. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@102863 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Feb 14, 2013
https://bugs.webkit.org/show_bug.cgi?id=65711 Reviewed by Zoltan Herczeg. Source/WebCore: Final patch fixing the performance regression from r81168 plus giving us more performance we ever had. The testcase attached to bug 65711 creates 200 tspans as <text> children, and modifies just the first <tspan>s content periodically using a timer. It ran with <3 FPS in release builds before, and now at around 60 FPS, where the most dominant code path remaining is CG painting text. Still theres room to optimize further, as Intruments shows. Historically we rebuilt all SVGTextLayoutAttributes stored in the RenderSVGInlineText, whenever any children of the <text> subtree changed, in any way. This lead to a recomputation of the x/y/dx/dy/rotate value lists, for the whole tree, a recreation of the line box tree and finally a measurement of all characters in the subtree. This patch, and its previous patches preparing this, introduces progressive relayout for the SVG text subtree. DOM tree mutations, x/y/dx/dy/rotate value lists changes, and measuring-all-characters are now strictly decoupled. #1) x/y/dx/dy/rotate list changes: The x/y/dx/dy/rotate lists are only ever rebuilt, if they change or upon the initial RenderSVGText layout. This information is now cached in the so-called SVGCharacterDataMap, in each of the SVGTextLayoutAttributes, associated with a specific RenderSVGInlineText. #2) DOM tree mutations: If a new RenderSVGInlineText gets added to the tree, we have to create SVGTextLayoutAttributes for the new renderer, measure its characters, and cache the information in the attributes. Adding a new renderer to a SVG <text> subtree can affect the positioning of the previous and next sibling in the tree, due the whitespace merging logic. Example: <text y="50" x="50 100 150">A<tspan></tspan> C</text>: RenderSVGText {text} at (50,36) size 111x18 contains 1 chunk(s) RenderSVGInlineText {#text} at (0,0) size 12x18 chunk 1 text run 1 at (50.00,50.00) startOffset 0 endOffset 1 width 12.00: "A" RenderSVGTSpan {tspan} at (0,0) size 0x0 RenderSVGInlineText {#text} at (50,0) size 61x18 chunk 1 text run 1 at (100.00,50.00) startOffset 0 endOffset 1 width 4.00: " " chunk 1 text run 1 at (150.00,50.00) startOffset 0 endOffset 1 width 11.00: "C" <text y="50" x="50 100 150">A<tspan>B</tspan> C</text>: RenderSVGText {text} at (50,36) size 115x18 contains 1 chunk(s) RenderSVGInlineText {#text} at (0,0) size 12x18 chunk 1 text run 1 at (50.00,50.00) startOffset 0 endOffset 1 width 12.00: "A" RenderSVGTSpan {tspan} at (0,0) size 11x18 RenderSVGInlineText {#text} at (50,0) size 11x18 chunk 1 text run 1 at (100.00,50.00) startOffset 0 endOffset 1 width 11.00: "B" RenderSVGInlineText {#text} at (100,0) size 15x18 chunk 1 text run 1 at (150.00,50.00) startOffset 0 endOffset 2 width 15.00: " C" Its obvious that adding a #text node as child to the <tspan> potentially affects the next & previous siblings in the DOM tree. Take extra care of these possibilities, by properly remeasuring not only the newly added renderer, but also the previous & next siblings layout attributes. Mutation of text nodes, or removal of text/tspan elements from the tree is handled in the same way. #3) Measuring the text subtree: Don't cache the metrics information in the SVGRootInlineBox, as it doesn't survive relayouts (RenderSVGText::layout). They're stored in the SVGTextLayoutAttributes, and will be updated if the underlying text content changes. Tests: svg/text/append-text-node-to-tspan.html svg/text/modify-text-node-in-tspan.html svg/text/remove-text-node-from-tspan.html * rendering/svg/RenderSVGInline.cpp: (WebCore::RenderSVGInline::addChild): * rendering/svg/RenderSVGInline.h: * rendering/svg/RenderSVGInlineText.cpp: (WebCore::RenderSVGInlineText::willBeDestroyed): (WebCore::RenderSVGInlineText::setTextInternal): (WebCore::RenderSVGInlineText::styleDidChange): * rendering/svg/RenderSVGInlineText.h: (WebCore::RenderSVGInlineText::layoutAttributes): * rendering/svg/RenderSVGText.cpp: (WebCore::recursiveUpdateLayoutAttributes): (WebCore::RenderSVGText::layoutAttributesChanged): (WebCore::findPreviousAndNextAttributes): (WebCore::RenderSVGText::layoutAttributesWillBeDestroyed): (WebCore::RenderSVGText::textDOMChanged): (WebCore::RenderSVGText::layout): (WebCore::RenderSVGText::addChild): (WebCore::recursiveCollectLayoutAttributes): (WebCore::RenderSVGText::rebuildLayoutAttributes): * rendering/svg/RenderSVGText.h: (WebCore::RenderSVGText::layoutAttributes): * rendering/svg/SVGRootInlineBox.cpp: (WebCore::SVGRootInlineBox::computePerCharacterLayoutInformation): (WebCore::findFirstAndLastAttributesInVector): (WebCore::reverseInlineBoxRangeAndValueListsIfNeeded): (WebCore::SVGRootInlineBox::reorderValueLists): * rendering/svg/SVGRootInlineBox.h: * rendering/svg/SVGTextLayoutAttributes.h: * rendering/svg/SVGTextLayoutAttributesBuilder.cpp: (WebCore::SVGTextLayoutAttributesBuilder::rebuildMetricsForWholeTree): * rendering/svg/SVGTextLayoutEngine.cpp: (WebCore::SVGTextLayoutEngine::SVGTextLayoutEngine): (WebCore::SVGTextLayoutEngine::currentLogicalCharacterAttributes): (WebCore::SVGTextLayoutEngine::currentLogicalCharacterMetrics): (WebCore::SVGTextLayoutEngine::currentVisualCharacterMetrics): (WebCore::SVGTextLayoutEngine::layoutTextOnLineOrPath): * rendering/svg/SVGTextLayoutEngine.h: (WebCore::SVGTextLayoutEngine::layoutAttributes): * rendering/svg/SVGTextMetrics.h: * rendering/svg/SVGTextMetricsBuilder.cpp: (WebCore::SVGTextMetricsBuilder::measureTextRenderer): * rendering/svg/SVGTextQuery.cpp: (WebCore::SVGTextQuery::modifyStartEndPositionsRespectingLigatures): * svg/SVGTextContentElement.cpp: (WebCore::SVGTextContentElement::childrenChanged): LayoutTests: Update some results, that changed again slightly. Land new tests covering partial SVG <text> subtree updating. * platform/chromium/test_expectations.txt: * platform/mac/svg/carto.net/window-expected.png: * platform/mac/svg/carto.net/window-expected.txt: * platform/mac/svg/custom/js-late-clipPath-and-object-creation-expected.png: * platform/mac/svg/custom/js-late-clipPath-and-object-creation-expected.txt: * platform/mac/svg/custom/js-late-gradient-and-object-creation-expected.png: * platform/mac/svg/custom/js-late-gradient-and-object-creation-expected.txt: * platform/mac/svg/custom/js-late-pattern-and-object-creation-expected.png: * platform/mac/svg/custom/js-late-pattern-and-object-creation-expected.txt: * platform/mac/svg/custom/use-detach-expected.png: * platform/mac/svg/custom/use-detach-expected.txt: * platform/mac/svg/text/append-text-node-to-tspan-expected.png: Added. * platform/mac/svg/text/append-text-node-to-tspan-expected.txt: Added. * platform/mac/svg/text/modify-text-node-in-tspan-expected.png: Added. * platform/mac/svg/text/modify-text-node-in-tspan-expected.txt: Added. * platform/mac/svg/text/remove-text-node-from-tspan-expected.png: Added. * platform/mac/svg/text/remove-text-node-from-tspan-expected.txt: Added. * svg/text/append-text-node-to-tspan.html: Added. * svg/text/modify-text-node-in-tspan.html: Added. * svg/text/remove-text-node-from-tspan.html: Added. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@105143 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Feb 14, 2013
https://bugs.webkit.org/show_bug.cgi?id=78454 Unreviewed. Rebaseline #3 of N * fast/backgrounds/size/backgroundSize21-expected.txt: Renamed from LayoutTests/platform/gtk/fast/backgrounds/size/backgroundSize21-expected.txt. * fast/backgrounds/size/backgroundSize22-expected.txt: Renamed from LayoutTests/platform/gtk/fast/backgrounds/size/backgroundSize22-expected.txt. * platform/chromium-mac-snowleopard/fast/backgrounds/size/backgroundSize21-expected.png: Added. * platform/chromium-mac-snowleopard/fast/backgrounds/size/backgroundSize22-expected.png: Added. * platform/chromium-mac/fast/backgrounds/size/backgroundSize21-expected.png: Removed. * platform/chromium-mac/fast/backgrounds/size/backgroundSize22-expected.png: Removed. * platform/chromium-win/fast/backgrounds/size/backgroundSize21-expected.png: * platform/chromium-win/fast/backgrounds/size/backgroundSize22-expected.png: * platform/chromium/test_expectations.txt: * platform/mac/fast/backgrounds/size/backgroundSize21-expected.txt: Removed. * platform/mac/fast/backgrounds/size/backgroundSize22-expected.txt: Removed. * platform/qt/fast/backgrounds/size/backgroundSize21-expected.txt: Removed. * platform/qt/fast/backgrounds/size/backgroundSize22-expected.txt: Removed. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@107671 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Feb 14, 2013
https://bugs.webkit.org/show_bug.cgi?id=81206 Reviewed by Adam Barth. Patch #3 in a series of patches to change the PeerConnection from ROAP to JSEP, see bug 80589 for more information. Adding the SessionDescription JS object and its platform counterpart SessionDescriptionDescriptor. Not possible to test until the entire JSEP feature is commited. * GNUmakefile.list.am: * Modules/mediastream/SessionDescription.cpp: Copied from Source/WebCore/platform/mediastream/MediaStreamCenter.cpp. (WebCore): (WebCore::SessionDescription::create): (WebCore::SessionDescription::SessionDescription): (WebCore::SessionDescription::~SessionDescription): (WebCore::SessionDescription::addCandidate): (WebCore::SessionDescription::toSdp): (WebCore::SessionDescription::descriptor): * Modules/mediastream/SessionDescription.h: Copied from Source/WebCore/platform/mediastream/MediaStreamCenter.cpp. (WebCore): (SessionDescription): * Modules/mediastream/SessionDescription.idl: Added. * WebCore.gypi: * platform/mediastream/MediaStreamCenter.cpp: (WebCore::MediaStreamCenter::constructSdp): (WebCore): * platform/mediastream/MediaStreamCenter.h: (WebCore): (MediaStreamCenter): * platform/mediastream/SessionDescriptionDescriptor.cpp: Copied from Source/WebCore/platform/mediastream/MediaStreamCenter.cpp. (WebCore): (WebCore::SessionDescriptionDescriptor::create): (WebCore::SessionDescriptionDescriptor::SessionDescriptionDescriptor): (WebCore::SessionDescriptionDescriptor::~SessionDescriptionDescriptor): (WebCore::SessionDescriptionDescriptor::addCandidate): (WebCore::SessionDescriptionDescriptor::toSdp): (WebCore::SessionDescriptionDescriptor::numberOfAddedCandidates): (WebCore::SessionDescriptionDescriptor::candidate): (WebCore::SessionDescriptionDescriptor::initialSdp): * platform/mediastream/SessionDescriptionDescriptor.h: Copied from Source/WebCore/platform/mediastream/MediaStreamCenter.cpp. (WebCore): (SessionDescriptionDescriptor): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@110943 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Feb 14, 2013
https://bugs.webkit.org/show_bug.cgi?id=92487 Patch by Mike West <mkwst@chromium.org> on 2012-07-27 Reviewed by Adam Barth. Source/WebCore: Unknown directive names are currently logged, but we exit the directive parser early without logging if we hit an invalid character inside a directive. `script-src: ...`, for example, was ignored without letting the developer know what happened. This patch changes that behavior, logging the whole name (in this case `script-src:`) as an unknown directive. Test: http/tests/security/contentSecurityPolicy/directive-parsing-04.html * page/ContentSecurityPolicy.cpp: (WebCore::CSPDirectiveList::parseDirective): LayoutTests: * http/tests/security/contentSecurityPolicy/directive-parsing-03-expected.txt: Added. * http/tests/security/contentSecurityPolicy/directive-parsing-04-expected.txt: Added. * http/tests/security/contentSecurityPolicy/directive-parsing-04.html: Added. Adding a test specifically for `script-src: ...` which bit me, and updating test #3, which now has a better error message. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123899 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Feb 14, 2013
https://bugs.webkit.org/show_bug.cgi?id=99899 Reviewed by Ryosuke Niwa. We cannot provide an elegant way to measure the memory consumption of the PageLoad tests, but we can turn them into simple performance tests and measure their memory footprint and performance that way. This change moves and renames the related files to their new location and adds html/js wrappers for them. This is the #3 commit of the whole patch. * PageLoad/svg/files/42470-flower_from_my_garden_v2.svg: Removed. * PageLoad/svg/files/44057-drops on a blade.svg: Removed. * PageLoad/svg/files/deb9frac1.svg: Removed. * PageLoad/svg/files/food_leif_lodahl_01.svg: Removed. * SVG/Debian.html: Added. * SVG/DropsOnABlade.html: Added. * SVG/FlowerFromMyGarden.html: Added. * SVG/FoodLeifLodahl.html: Added. * SVG/resources/Debian.svg: Copied from PerformanceTests/PageLoad/svg/files/deb9frac1.svg. * SVG/resources/DropsOnABlade.svg: Copied from PerformanceTests/PageLoad/svg/files/44057-drops%20on%20a%20blade.svg. * SVG/resources/FlowerFromMyGarden.svg: Copied from PerformanceTests/PageLoad/svg/files/42470-flower_from_my_garden_v2.svg. * SVG/resources/FoodLeifLodahl.svg: Copied from PerformanceTests/PageLoad/svg/files/food_leif_lodahl_01.svg. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@132531 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
May 12, 2013
…tml and css3/selectors/xml tests after enabling the subpixel layout. Patch #3 of many more. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148799 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Jul 28, 2013
… read and what they write https://bugs.webkit.org/show_bug.cgi?id=118910 Source/JavaScriptCore: Reviewed by Sam Weinig. Add the notion of AbstractHeap to the DFG. This is analogous to the AbstractHeap in the FTL, except that the FTL's AbstractHeaps are used during LLVM lowering and are engineered to obey LLVM TBAA logic. The FTL's AbstractHeaps are also engineered to be inexpensive to use (they just give you a TBAA node) but expensive to create (you create them all up front). FTL AbstractHeaps also don't actually give you the ability to reason about aliasing; they are *just* a mechanism for lowering to TBAA. The DFG's AbstractHeaps are engineered to be both cheap to create and cheap to use. They also give you aliasing machinery. The DFG AbstractHeaps are represented internally by a int64_t. Many comparisons between them are just integer comaprisons. AbstractHeaps form a three-level hierarchy (World is the supertype of everything, Kind with a TOP payload is a direct subtype of World, and Kind with a non-TOP payload is the direct subtype of its corresponding TOP Kind). Add the notion of a ClobberSet. This is the set of AbstractHeaps that you had clobbered. It represents the set that results from unifying a bunch of AbstractHeaps, and is intended to quickly answer overlap questions: does the given AbstractHeap overlap any AbstractHeap in the ClobberSet? To this end, if you add an AbstractHeap to a set, it "directly" adds the heap itself, and "super" adds all of its ancestors. An AbstractHeap is said to overlap a set if any direct or super member is equal to it, or if any of its ancestors are equal to a direct member. Example #1: - I add Variables(5). I.e. Variables is the Kind and 5 is the payload. This is a subtype of Variables, which is a subtype of World. - You query Variables. I.e. Variables with a TOP payload, which is the supertype of Variables(X) for any X, and a subtype of World. The set will have Variables(5) as a direct member, and Variables and World as super members. The Variables query will immediately return true, because Variables is indeed a super member. Example #2: - I add Variables(5) - You query NamedProperties NamedProperties is not a member at all (neither direct or super). We next query World. World is a member, but it's a super member, so we return false. Example #3: - I add Variables - You query Variables(5) The set will have Variables as a direct member, and World as a super member. The Variables(5) query will not find Variables(5) in the set, but then it will query Variables. Variables is a direct member, so we return true. Example #4: - I add Variables - You query NamedProperties(5) Neither NamedProperties nor NamedProperties(5) are members. We next query World. World is a member, but it's a super member, so we return false. Overlap queries require that either the heap being queried is in the set (either direct or super), or that one of its ancestors is a direct member. Another way to think about how this works is that two heaps A and B are said to overlap if A.isSubtypeOf(B) or B.isSubtypeOf(A). This is sound since heaps form a single-inheritance heirarchy. Consider that we wanted to implement a set that holds heaps and answers the question, "is any member in the set an ancestor (i.e. supertype) of some other heap". We would have the set contain the heaps themselves, and we would satisfy the query "A.isSubtypeOfAny(set)" by walking the ancestor chain of A, and repeatedly querying its membership in the set. This is what the "direct" members of our set do. Now consider the other part, where we want to ask if any member of the set is a descendent of a heap, or "A.isSupertypeOfAny(set)". We would implement this by implementing set.add(B) as adding not just B but also all of B's ancestors; then we would answer A.isSupertypeOfAny(set) by just checking if A is in the set. With two such sets - one that answers isSubtypeOfAny() and another that answers isSupertypeOfAny() - we could answer the "do any of my heaps overlap your heap" question. ClobberSet does this, but combines the two sets into a single HashMap. The HashMap's value, "direct", means that the key is a member of both the supertype set and the subtype set; if it's false then it's only a member of one of them. Finally, this adds a functorized clobberize() method that adds the read and write clobbers of a DFG::Node to read and write functors. Common functors for adding to ClobberSets, querying overlap, and doing nothing are provided. Convenient wrappers are also provided. This allows you to say things like: ClobberSet set; addWrites(graph, node1, set); if (readsOverlap(graph, node2, set)) // We know that node1 may write to something that node2 may read from. Currently this facility is only used to improve graph dumping, but it will be instrumental in both LICM and GVN. In the future, I want to completely kill the NodeClobbersWorld and NodeMightClobber flags, and eradicate CSEPhase's hackish way of accomplishing almost exactly what AbstractHeap gives you. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractHeap.cpp: Added. (DFG): (JSC::DFG::AbstractHeap::Payload::dump): (JSC::DFG::AbstractHeap::dump): (WTF): (WTF::printInternal): * dfg/DFGAbstractHeap.h: Added. (DFG): (AbstractHeap): (Payload): (JSC::DFG::AbstractHeap::Payload::Payload): (JSC::DFG::AbstractHeap::Payload::top): (JSC::DFG::AbstractHeap::Payload::isTop): (JSC::DFG::AbstractHeap::Payload::value): (JSC::DFG::AbstractHeap::Payload::valueImpl): (JSC::DFG::AbstractHeap::Payload::operator==): (JSC::DFG::AbstractHeap::Payload::operator!=): (JSC::DFG::AbstractHeap::Payload::operator<): (JSC::DFG::AbstractHeap::Payload::isDisjoint): (JSC::DFG::AbstractHeap::Payload::overlaps): (JSC::DFG::AbstractHeap::AbstractHeap): (JSC::DFG::AbstractHeap::operator!): (JSC::DFG::AbstractHeap::kind): (JSC::DFG::AbstractHeap::payload): (JSC::DFG::AbstractHeap::isDisjoint): (JSC::DFG::AbstractHeap::overlaps): (JSC::DFG::AbstractHeap::supertype): (JSC::DFG::AbstractHeap::hash): (JSC::DFG::AbstractHeap::operator==): (JSC::DFG::AbstractHeap::operator!=): (JSC::DFG::AbstractHeap::operator<): (JSC::DFG::AbstractHeap::isHashTableDeletedValue): (JSC::DFG::AbstractHeap::payloadImpl): (JSC::DFG::AbstractHeap::encode): (JSC::DFG::AbstractHeapHash::hash): (JSC::DFG::AbstractHeapHash::equal): (AbstractHeapHash): (WTF): * dfg/DFGClobberSet.cpp: Added. (DFG): (JSC::DFG::ClobberSet::ClobberSet): (JSC::DFG::ClobberSet::~ClobberSet): (JSC::DFG::ClobberSet::add): (JSC::DFG::ClobberSet::addAll): (JSC::DFG::ClobberSet::contains): (JSC::DFG::ClobberSet::overlaps): (JSC::DFG::ClobberSet::clear): (JSC::DFG::ClobberSet::direct): (JSC::DFG::ClobberSet::super): (JSC::DFG::ClobberSet::dump): (JSC::DFG::ClobberSet::setOf): (JSC::DFG::addReads): (JSC::DFG::addWrites): (JSC::DFG::addReadsAndWrites): (JSC::DFG::readsOverlap): (JSC::DFG::writesOverlap): * dfg/DFGClobberSet.h: Added. (DFG): (ClobberSet): (JSC::DFG::ClobberSet::isEmpty): (ClobberSetAdd): (JSC::DFG::ClobberSetAdd::ClobberSetAdd): (JSC::DFG::ClobberSetAdd::operator()): (ClobberSetOverlaps): (JSC::DFG::ClobberSetOverlaps::ClobberSetOverlaps): (JSC::DFG::ClobberSetOverlaps::operator()): (JSC::DFG::ClobberSetOverlaps::result): * dfg/DFGClobberize.cpp: Added. (DFG): (JSC::DFG::didWrites): * dfg/DFGClobberize.h: Added. (DFG): (JSC::DFG::clobberize): (NoOpClobberize): (JSC::DFG::NoOpClobberize::NoOpClobberize): (JSC::DFG::NoOpClobberize::operator()): (CheckClobberize): (JSC::DFG::CheckClobberize::CheckClobberize): (JSC::DFG::CheckClobberize::operator()): (JSC::DFG::CheckClobberize::result): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): Source/WTF: Reviewed by Sam Weinig. Fix compile goof in sortedListDump(). * wtf/ListDump.h: (WTF::sortedListDump): Conflicts: Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153294 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Sep 21, 2013
…th DFG and FTL https://bugs.webkit.org/show_bug.cgi?id=121371 Reviewed by Sam Weinig. Forward rewiring is a tricky part of OSR that handles the following: a: Something(...) SetLocal(@A, locX) b: Int32ToDouble(@A) c: SomethingThatExits(@b) <no further uses of @A or @b> Note that at @c, OSR will think that locX->@A, but @A will be dead. So it must be smart enough to find @b, which contains an equivalent value. It must do this for any identity functions we support. Currently we support four such functions. Currently the code for doing this is basically duplicated between the DFG and the FTL. Also both versions of the code have some really weirdly written logic for picking the "best" identity function to use. We should fix this by simply having a way to ask "is this node an identity function, and if so, then how good is it?" Then both the DFG and FTL could use this and have no hard-wired knowledge of those identity functions. While we're at it, this also changes some terminology because I found the use of the word "needs" confusing. Note that this retains the somewhat confusing behavior that we don't search all possible forward/backward uses. We only search one step in each direction. This is because we only need to handle cases that FixupPhase and the parser insert. All other code that tries to insert intermediate conversion nodes should ensure to Phantom the original node. For example, the following transformation is illegal: Before: x: SomethingThatExits(@A) After: w: Conversion(@A) x: SomethingThatExits(@w) The correct form of that transformation is one of these: Correct #1: v: DoAllChecks(@A) // exit here w: Conversion(@A) x: Something(@w) // no exit Correct #2: w: Conversion(@A) x: SomethingThatExits(@w) y: Phantom(@A) Correct #3: w: Conversion(@A) x: SomethingThatExits(@w, @A) Note that we use #3 for some heap accesses, but of course it requires that the node you're using has an extra slot for a "dummy" use child. Broadly speaking though, such transformations should be relegated to something below DFG IR, like LLVM IR. * dfg/DFGNodeType.h: (JSC::DFG::forwardRewiringSelectionScore): (JSC::DFG::needsOSRForwardRewiring): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155793 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Oct 14, 2013
…hread (causing scroll bars not to appear/update quickly in some cases) https://bugs.webkit.org/show_bug.cgi?id=122585 -and corresponding- <rdar://problem/10710775> Reviewed by Simon Fraser. Source/WebCore: This patch does a few things in order to allow scrollbars to be updated on the scrolling thread: 1. This patch adds the ability to know if the lower-level APIs necessary to get this to work right are available, AND if the content is actually capable of taking advantage of this feature. This is currently implemented as Scrollbar::supportsUpdateOnSecondaryThread() which makes use of a new ScrollableArea function called updatesScrollLayerPositionOnMainThread() 2. To update on the scrolling thread, the scrolling tree needs to know about the ScrollbarPainters. 3. Once it knows about them, it should update the presentation value whenever the layer position changes. 4. Presentation value is basically the same thing as double value. There is a bit of code we maintain currently to compute that. This patch moves that code to a static function on ScrollableArea that can be called from both the main thread and the scrolling thread. 5. ScrollbarPainter API needs to know about the layers we have created for the vertical and horizontal scrollbars, then they will use those layers and the presentation value that we set on the scrolling thread to move the layers around. This is part of #1 above. * page/FrameView.cpp: (WebCore::FrameView::updatesScrollLayerPositionOnMainThread): * page/FrameView.h: This is part of #2. ScrollingStateScrollingNodes now have vertical and horizontal ScrollbarPainters for Mac only. * page/scrolling/ScrollingStateScrollingNode.cpp: (WebCore::ScrollingStateScrollingNode::ScrollingStateScrollingNode): * page/scrolling/ScrollingStateScrollingNode.h: (WebCore::ScrollingStateScrollingNode::verticalScrollbarPainter): (WebCore::ScrollingStateScrollingNode::horizontalScrollbarPainter): Also part of #2. Make sure to set the ScrollbarPainters for scrolling nodes when appropriate. * page/scrolling/mac/ScrollingCoordinatorMac.h: * page/scrolling/mac/ScrollingCoordinatorMac.mm: (WebCore::ScrollingCoordinatorMac::frameViewLayoutUpdated): Implement this function that was just stubbed out before. This is part of #5 in that is will allow the ScrollbarPainter API to know about any layer changes. (WebCore::ScrollingCoordinatorMac::scrollableAreaScrollbarLayerDidChange): Back to #2, making sure we properly set the ScrollbarPainters to send over to the scrolling thread. (WebCore::ScrollingCoordinatorMac::setScrollbarPaintersForNode): * page/scrolling/mac/ScrollingStateScrollingNodeMac.mm: (WebCore::ScrollingStateScrollingNode::setScrollbarPainters): This code achieves #3. It uses new ScrollbarPainter API to adjust the position of the scrollbars from the scrolling thread. * page/scrolling/mac/ScrollingTreeScrollingNodeMac.h: * page/scrolling/mac/ScrollingTreeScrollingNodeMac.mm: (WebCore::ScrollingTreeScrollingNodeMac::ScrollingTreeScrollingNodeMac): (WebCore::ScrollingTreeScrollingNodeMac::updateBeforeChildren): (WebCore::ScrollingTreeScrollingNodeMac::setScrollLayerPosition): This is for #5. ScrollbarPainter needs to know about our scrollbar layers. * platform/ScrollAnimator.h: (WebCore::ScrollAnimator::verticalScrollbarLayerDidChange): (WebCore::ScrollAnimator::horizontalScrollbarLayerDidChange): * platform/ScrollableArea.cpp: (WebCore::ScrollableArea::verticalScrollbarLayerDidChange): (WebCore::ScrollableArea::horizontalScrollbarLayerDidChange): This is for #4. This code computes the scrollbar’s value and current overhang amount. (WebCore::ScrollableArea::computeScrollbarValueAndOverhang): * platform/ScrollableArea.h: (WebCore::ScrollableArea::layerForHorizontalScrollbar): (WebCore::ScrollableArea::layerForVerticalScrollbar): (WebCore::ScrollableArea::layerForScrolling): This is for #1. We need to know if we have the ability to update scrollbars on a different thread. We can do that only on certain versions of the OS, only when threaded scrolling is enabled, and only when the current page is actually using the scrolling thread to scroll. * platform/Scrollbar.cpp: (WebCore::Scrollbar::supportsUpdateOnSecondaryThread): * platform/Scrollbar.h: * platform/ScrollbarThemeClient.h: New ScrollbarPainter APIs. * platform/mac/NSScrollerImpDetails.h: This is for #5, letting the ScrollbarPainter API know about the layers. * platform/mac/ScrollAnimatorMac.h: * platform/mac/ScrollAnimatorMac.mm: (-[WebScrollbarPainterDelegate layer]): (-[WebScrollbarPainterDelegate convertRectToLayer:]): (-[WebScrollbarPainterDelegate shouldUseLayerPerPartForScrollerImp:]): Before we kick off a scroll animation, set the current painting characteristics so they are up-to-date in case we are scrolling on the scrolling thread. (-[WebScrollbarPainterDelegate setUpAlphaAnimation:scrollerPainter:part:WebCore::animateAlphaTo:duration:]): (-[WebScrollbarPainterDelegate scrollerImp:animateKnobAlphaTo:duration:]): (-[WebScrollbarPainterDelegate scrollerImp:animateTrackAlphaTo:duration:]): (WebCore::ScrollAnimatorMac::didAddVerticalScrollbar): (WebCore::ScrollAnimatorMac::didAddHorizontalScrollbar): (WebCore::ScrollAnimatorMac::verticalScrollbarLayerDidChange): (WebCore::ScrollAnimatorMac::horizontalScrollbarLayerDidChange): Only paint the scrollbars through ScrollbarThemeMac if they are NOT being updated by the scrolling thread. * platform/mac/ScrollbarThemeMac.h: * platform/mac/ScrollbarThemeMac.mm: (WebCore::ScrollbarThemeMac::setCurrentPaintCharacteristics): (WebCore::scrollbarPainterPaint): (WebCore::ScrollbarThemeMac::paint): Back to #1. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::updatesScrollLayerPositionOnMainThread): * rendering/RenderLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::updateOverflowControlsLayers): * rendering/RenderListBox.h: Source/WebKit2: New pure virtual function. * WebProcess/Plugins/PDF/PDFPlugin.h: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157253 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
May 24, 2014
https://bugs.webkit.org/show_bug.cgi?id=127835 Source/WebCore: In some cases when a negative margin and a positive padding are applied together to the right and/or left side of the box, the logical width of the borders can be set to a negative value, making the assertion fire. The fix checks if the width or height of the box is negative, and if so, it will not display the borders and shadows of the box. Patch by Martin Hodovan <mhodovan@inf.u-szeged.hu> on 2014-04-16 Reviewed by Darin Adler. Test: fast/css/padding-margin-negative-border.html * rendering/RenderBoxModelObject.cpp: (WebCore::RenderBoxModelObject::paintBorder): LayoutTests: Added test demonstrates four cases: Test #1: Negative upper margin + positive upper padding Test #2: Negative right margin + positive right padding (used to fail) Test #3: Negative bottom margin + positive bottom padding Test #4: Negative left margin + positive left padding (used to fail) Patch by Martin Hodovan <mhodovan@inf.u-szeged.hu> on 2014-04-16 Reviewed by Darin Adler. * fast/css/padding-margin-negative-border-expected.html: Added. * fast/css/padding-margin-negative-border.html: Added. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167351 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When starting replay, the document's size should be initialized to match the starting size during capture.
The text was updated successfully, but these errors were encountered: