The Timelapse FAQ page is out of date #4
Labels
Comments
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 #4 commit of the whole patch. * PageLoad/svg/files/france.svg: Removed. * PageLoad/svg/files/francobollo_gnome_ezechi_02.svg: Removed. * SVG/France.html: Added. * SVG/FrancoBolloGnomeEzechi.html: Added. * SVG/resources/France.svg: Copied from PerformanceTests/PageLoad/svg/files/france.svg. * SVG/resources/FrancoBolloGnomeEzechi.svg: Copied from PerformanceTests/PageLoad/svg/files/francobollo_gnome_ezechi_02.svg. * Skipped: Rename the files on the skipped list also. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@132544 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=78454 Unreviewed. Rebaseline #4 of N * platform/chromium-linux/fast/block/float/014-expected.png: * platform/chromium-linux/fast/repaint/block-layout-inline-children-replaced-expected.png: * platform/chromium-mac-leopard/fast/block/float/014-expected.png: * platform/chromium-mac-leopard/fast/repaint/block-layout-inline-children-replaced-expected.png: * platform/chromium-mac-snowleopard/fast/block/float/014-expected.png: Added. * platform/chromium-mac-snowleopard/fast/repaint/block-layout-inline-children-replaced-expected.png: * platform/chromium-mac/fast/block/float/014-expected.png: Removed. * platform/chromium-win/fast/block/float/014-expected.png: * platform/chromium-win/fast/repaint/block-layout-inline-children-replaced-expected.png: * platform/chromium/test_expectations.txt: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@107673 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Feb 14, 2013
https://bugs.webkit.org/show_bug.cgi?id=81207 Reviewed by Adam Barth. Patch #4 in a series of patches to change the PeerConnection from ROAP to JSEP, see bug 80589 for more information. Introducing the platform MediaHints and IceOptions helper classes. Not possible to test until the entire JSEP feature is commited. * GNUmakefile.list.am: * WebCore.gypi: * platform/mediastream/IceOptions.cpp: Added. (WebCore): (WebCore::IceOptions::create): * platform/mediastream/IceOptions.h: Added. (WebCore): (IceOptions): (WebCore::IceOptions::~IceOptions): (WebCore::IceOptions::useCandidates): (WebCore::IceOptions::IceOptions): * platform/mediastream/MediaHints.cpp: Added. (WebCore): (WebCore::MediaHints::create): (WebCore::MediaHints::audio): (WebCore::MediaHints::video): * platform/mediastream/MediaHints.h: Added. (WebCore): (MediaHints): (WebCore::MediaHints::~MediaHints): (WebCore::MediaHints::MediaHints): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@110937 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 #4 commit of the whole patch. * PageLoad/svg/files/france.svg: Removed. * PageLoad/svg/files/francobollo_gnome_ezechi_02.svg: Removed. * SVG/France.html: Added. * SVG/FrancoBolloGnomeEzechi.html: Added. * SVG/resources/France.svg: Copied from PerformanceTests/PageLoad/svg/files/france.svg. * SVG/resources/FrancoBolloGnomeEzechi.svg: Copied from PerformanceTests/PageLoad/svg/files/francobollo_gnome_ezechi_02.svg. * Skipped: Rename the files on the skipped list also. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@132544 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
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
It needs to not talk about network proxying, since we don't use a proxy any more.
The text was updated successfully, but these errors were encountered: