diff options
Diffstat (limited to 'Source/WebCore/ChangeLog')
| -rw-r--r-- | Source/WebCore/ChangeLog | 379 |
1 files changed, 379 insertions, 0 deletions
diff --git a/Source/WebCore/ChangeLog b/Source/WebCore/ChangeLog index 11f0168..c877435 100644 --- a/Source/WebCore/ChangeLog +++ b/Source/WebCore/ChangeLog @@ -1,5 +1,384 @@ +2012-03-16 Kentaro Hara <haraken@chromium.org> + + [Performance] Optimize innerHTML and outerHTML + https://bugs.webkit.org/show_bug.cgi?id=81214 + + Reviewed by Adam Barth. + + This patch makes innerHTML and outerHTML 2.4 times faster. + + Performance test: https://bugs.webkit.org/attachment.cgi?id=132034 + The performance test measures body.innerHTML for 3000 lines of HTML, + which is copied from the HTML spec. + + - Chromium/Mac without the patch + div.innerHTML: 1658.6 ms + div.outerHTML: 4859.6 ms + body.innerHTML: 640.2 ms + body.outerHTML: 641.8 ms + + - Chromium/Mac with the patch + div.innerHTML: 751.0 ms + div.outerHTML: 2096.0 ms + body.innerHTML: 271.2 ms + body.outerHTML: 271.2 ms + + - Chromium/Linux without the patch + div.innerHTML: 950.4 ms + div.outerHTML: 2257.8 ms + body.innerHTML: 452.8 ms + body.outerHTML: 457.6 ms + + - Chromium/Linux with the patch + div.innerHTML: 582.4 ms + div.outerHTML: 1283.0 ms + body.innerHTML: 233.0 ms + body.outerHTML: 233.4 ms + + - AppleWebKit/Mac without the patch + div.innerHTML: 900.6 ms + div.outerHTML: 2245.2 ms + body.innerHTML: 462.6 ms + body.outerHTML: 468.0 ms + + - AppleWebKit/Mac with the patch + div.innerHTML: 529.8 ms + div.outerHTML: 1090.2 ms + body.innerHTML: 239.2 ms + body.outerHTML: 239.2 ms + + This patch applies the following two optimizations: + + (a) Remove redundant copies between Vector<String> and StringBuilders + in MarkupAccumulator::serializeNodes(), MarkupAccumulator::appendStartTag(), + and MarkupAccumulator::appendEndTag(). + + (Previous behavior) + - Create a StringBuilder for each tag. + - Append a created string in each StringBuilder to Vector<String>, + parsing the DOM tree. + - After the parsing, allocate a StringBuilder whose size is the sum + of all Strings in Vector<String>. + - Append all Strings in Vector<String> to the StringBuilder. + (New behavior) + - Allocate a StringBuilder with a default buffer size. + - Append created strings to the StringBuilder, incrementally parsing + the DOM tree. + + (b) Optimize stringBuilder.append(). + (b-1) Replace stringBuilder.append("A") with stringBuilder.append('A'). + stringBuilder.append("A") requires to cast the characters to LChar*, + and then call strlen("A"). stringBuilder.append('A') is faster. + (b-2) Replace stringBuilder.append("AB") with stringBuilder.append('A') + and stringBuilder.append('B'). In my experiment, appending characters + one by one is faster than appending the characters at a breath if the + number of characters is less than 3. + (b-3) Hard-code a string length; i.e. replace stringBuilder.append("ABCDE") + with stringBuilder.append("ABCDE", 5). While the former requires to call + strlen("ABCDE"), the latter does not. + + (a) improves performance by 170% ~ 200%. (b) improves performance by 30 ~ 40%. + + Tests: fast/dom/Range/range-extract-contents.html + fast/dom/serialize-nodes.xhtml + fast/dom/XMLSerializer.html + and all other tests that use innerHTML or outerHTML. + No change in the test results. + + * editing/MarkupAccumulator.cpp: + (WebCore::MarkupAccumulator::serializeNodes): + (WebCore::MarkupAccumulator::appendString): + (WebCore::MarkupAccumulator::appendStartTag): + (WebCore::MarkupAccumulator::appendEndTag): + (WebCore::MarkupAccumulator::concatenateMarkup): + (WebCore::MarkupAccumulator::appendQuotedURLAttributeValue): + (WebCore::MarkupAccumulator::appendComment): + (WebCore::MarkupAccumulator::appendDocumentType): + (WebCore::MarkupAccumulator::appendProcessingInstruction): + (WebCore::MarkupAccumulator::appendOpenTag): + (WebCore::MarkupAccumulator::appendAttribute): + (WebCore::MarkupAccumulator::appendCDATASection): + * editing/MarkupAccumulator.h: + (MarkupAccumulator): + +2012-06-27 Kentaro Hara <haraken@chromium.org> + + Performance: Optimize Dromaeo/dom-query.html by caching NodeRareData on Document + https://bugs.webkit.org/show_bug.cgi?id=90059 + + Reviewed by Ryosuke Niwa. + + This patch improves performance of document.getElementsBy*(). + e.g. the patch makes Dromaeo/dom-query.html 5.4% faster. + + Dromaeo/dom-query.html without the patch (Chromium/Linux): + 784714 runs/s, 765947 runs/s, 803109 runs/s, 804450 runs/s + + Dromaeo/dom-query.html with the patch (Chromium/Linux): + 839245 runs/s, 829867 runs/s, 811032 runs/s, 847486 runs/s + + Based on the assumption that document.getElementsByClassName(), + document.getElementsByTagName() and document.getElementsByName() + would be used frequently in the real world, this patch implements + a fast path for Document methods that require to access NodeRareData. + Specifically, this patch caches a pointer to NodeRareData on Document, + by which Document can access NodeRareData without looking up a HashMap. + + The only performance concern is the overhead of the isDocumentNode() check + that this patch added to Node::ensureRareData. However, I could not + observe any performance regression caused by the overhead. + + No tests. No change in behavior. + + * dom/Document.cpp: + (WebCore::Document::Document): + (WebCore::Document::setCachedRareData): I didn't inline this method, + since the inlining slightly regressed performance for some reason. + (WebCore): + * dom/Document.h: + (WebCore): + (WebCore::Document::cachedRareData): + (Document): + (~Document): Moved 'm_document = 0' to the tail of the destructor, + since isDocumentNode() has to return true in clearRareData() that is called + in ~Document(). + * dom/Node.cpp: + (WebCore::Node::ensureRareData): + (~Node): Moved the assertion into clearRareData(). + +2012-04-09 James Robinson <jamesr@chromium.org> + + Remove partially implemented per-Element visibility checks from requestAnimationFrame logic + https://bugs.webkit.org/show_bug.cgi?id=74232 + + Reviewed by Dean Jackson. + + The initial requestAnimationFrame implementation had an Element parameter as the second argument to the + function. This element was intended to convey the element associated with the animation so that when the element + was not visible the animation callback would not be run. The checked in implementation does a very limited check + - testing for display:none and being detached from the tree - but does it in a way that does not work correctly + if an element's visibility is manipulated by a callback running from a different document. It also adds + significant complexity to the code, making it less hackable and easy to introduce subtle security bugs or + infinite loops. + + This patch removes the parameter. Since it has always been marked optional, there is no web compat risk. + + If this functionality is added back in the future it needs to be implemented in a way that considers all + callbacks within a Page and not only those within a single Document. + +2011-12-16 Zhenyao Mo <zmo@google.com> + + Postpone deleteRenderbuffer/deleteTexture until all framebuffer attachment points are removed. + https://bugs.webkit.org/show_bug.cgi?id=74741 + + Reviewed by Kenneth Russell. + + Use WebGLObject's attachment count mechanism to track if a renderbuffer/texture + is still attached to framebuffers, and if its deletion should be delated or not. + + * html/canvas/WebGLFramebuffer.cpp: + (WebCore::WebGLFramebuffer::setAttachmentForBoundFramebuffer): + (WebCore::WebGLFramebuffer::getAttachment): + (WebCore::WebGLFramebuffer::removeAttachmentFromBoundFramebuffer): + (WebCore::WebGLFramebuffer::deleteObjectImpl): + (WebCore::WebGLFramebuffer::isBound): + * html/canvas/WebGLFramebuffer.h: + +2012-04-10 Zhenyao Mo <zmo@google.com> + + WebGLRenderingContext should defer caching program info + https://bugs.webkit.org/show_bug.cgi?id=83513 + + Reviewed by Kenneth Russell. + + * html/canvas/WebGLProgram.cpp: + (WebCore::WebGLProgram::WebGLProgram): + (WebCore::WebGLProgram::numActiveAttribLocations): call cacheInfoIfNeeded(); + (WebCore::WebGLProgram::getActiveAttribLocation): Ditto. + (WebCore::WebGLProgram::isUsingVertexAttrib0): Ditto. + (WebCore::WebGLProgram::getLinkStatus): Ditto. + (WebCore): + (WebCore::WebGLProgram::cacheActiveAttribLocations): + (WebCore::WebGLProgram::cacheInfoIfNeeded): Cache link status, active attire locations, etc if needed. + (WebCore::WebGLProgram::increaseLinkCount): also invalidate cached info. + * html/canvas/WebGLProgram.h: + (WebGLProgram): + * html/canvas/WebGLRenderingContext.cpp: + (WebCore): + (WebCore::WebGLRenderingContext::linkProgram): Do not cache program info immediately. + +2012-05-04 Zhenyao Mo <zmo@google.com> + + vertexAttribPointer needs to reject large negative offsets + https://bugs.webkit.org/show_bug.cgi?id=85117 + + Reviewed by Kenneth Russell. + + * html/canvas/WebGLRenderingContext.cpp: Use long long for GLsizeiptr and GLintptr + (WebCore): + (WebCore::WebGLRenderingContext::bufferData): + (WebCore::WebGLRenderingContext::bufferSubData): + (WebCore::WebGLRenderingContext::drawElements): + (WebCore::WebGLRenderingContext::getVertexAttribOffset): + (WebCore::WebGLRenderingContext::vertexAttribPointer): + * html/canvas/WebGLRenderingContext.h: Ditto + (WebGLRenderingContext): + * html/canvas/WebGLRenderingContext.idl: Ditto + +2011-05-11 Antoine Labour <piman@chromium.org> + * dom/Document.cpp: + (WebCore::Document::webkitRequestAnimationFrame): + * dom/Document.h: + * dom/RequestAnimationFrameCallback.h: + * dom/ScriptedAnimationController.cpp: + (WebCore::ScriptedAnimationController::registerCallback): + (WebCore::ScriptedAnimationController::serviceScriptedAnimations): + * dom/ScriptedAnimationController.h: + * page/DOMWindow.cpp: + (WebCore::DOMWindow::webkitRequestAnimationFrame): + * page/DOMWindow.h: + * page/DOMWindow.idl: + +2011-12-12 James Robinson <jamesr@chromium.org> + + Rename webkitCancelRequestAnimationFrame to webkitCancelAnimationFrame to match spec change + https://bugs.webkit.org/show_bug.cgi?id=74231 + + Reviewed by Simon Fraser. + + The RequestAnimationFrame spec has renamed cancelRequestAnimationFrame to cancelAnimationFrame in response to + feedback from Mozilla and Microsoft that the old name was too long and didn't parallel setTimeout/clearTimeout + and setInterval/clearInterval very well. This updates our IDL to match, while preserving the old name as an + alias to be compatible with current content. + + * dom/Document.cpp: + (WebCore::Document::webkitCancelAnimationFrame): + * dom/Document.h: + * page/DOMWindow.cpp: + (WebCore::DOMWindow::webkitCancelAnimationFrame): + * page/DOMWindow.h: + (WebCore::DOMWindow::webkitCancelRequestAnimationFrame): + * page/DOMWindow.idl: + +2011-09-26 James Robinson <jamesr@chromium.org> + + [mac] Timestamp parameter to requestAnimationFrame is busted in USE(REQUEST_ANIMATION_FRAME_TIMER) path + https://bugs.webkit.org/show_bug.cgi?id=68769 + + Reviewed by Simon Fraser. + + Convert the time parameter from double to DOMTimeStamp using convertSecondsToDOMTimeStamp rather than relying on + implicit double->long conversion, which ignores the units of the value. + + Test: fast/animation/request-animation-frame-timestamps-advance.html + + * dom/ScriptedAnimationController.cpp: + (WebCore::ScriptedAnimationController::animationTimerFired): + +2011-09-09 Chris Marrin <cmarrin@apple.com> + + requestAnimationFrame doesn't throttle on Mac + https://bugs.webkit.org/show_bug.cgi?id=67171 + + Reviewed by Simon Fraser. + + Changed requestAnimationFrame to use a Timer in ScriptedAnimationController + on Mac, rather than runLoopObservers. The Timer is throttled to fire no + faster than every 15ms. It is behind a WTF_USE_REQUEST_ANIMATION_FRAME_TIMER + flag and can be used by any implementation, but currently it is only enabled + by PLATFORM(MAC). + + * dom/ScriptedAnimationController.cpp: + (WebCore::ScriptedAnimationController::ScriptedAnimationController): + (WebCore::ScriptedAnimationController::resume): + (WebCore::ScriptedAnimationController::registerCallback): + (WebCore::ScriptedAnimationController::serviceScriptedAnimations): + (WebCore::ScriptedAnimationController::scheduleAnimation): + (WebCore::ScriptedAnimationController::animationTimerFired): + * dom/ScriptedAnimationController.h: + * loader/EmptyClients.h: + * page/Chrome.cpp: + (WebCore::Chrome::scheduleAnimation): + * page/ChromeClient.h: + 2011-05-11 Antoine Labour <piman@chromium.org> + * dom/Document.cpp: + (WebCore::Document::webkitRequestAnimationFrame): + * dom/Document.h: + * dom/RequestAnimationFrameCallback.h: + * dom/ScriptedAnimationController.cpp: + (WebCore::ScriptedAnimationController::registerCallback): + (WebCore::ScriptedAnimationController::serviceScriptedAnimations): + * dom/ScriptedAnimationController.h: + * page/DOMWindow.cpp: + (WebCore::DOMWindow::webkitRequestAnimationFrame): + * page/DOMWindow.h: + * page/DOMWindow.idl: + +2011-12-12 James Robinson <jamesr@chromium.org> + + Rename webkitCancelRequestAnimationFrame to webkitCancelAnimationFrame to match spec change + https://bugs.webkit.org/show_bug.cgi?id=74231 + + Reviewed by Simon Fraser. + + The RequestAnimationFrame spec has renamed cancelRequestAnimationFrame to cancelAnimationFrame in response to + feedback from Mozilla and Microsoft that the old name was too long and didn't parallel setTimeout/clearTimeout + and setInterval/clearInterval very well. This updates our IDL to match, while preserving the old name as an + alias to be compatible with current content. + + * dom/Document.cpp: + (WebCore::Document::webkitCancelAnimationFrame): + * dom/Document.h: + * page/DOMWindow.cpp: + (WebCore::DOMWindow::webkitCancelAnimationFrame): + * page/DOMWindow.h: + (WebCore::DOMWindow::webkitCancelRequestAnimationFrame): + * page/DOMWindow.idl: + +2011-09-26 James Robinson <jamesr@chromium.org> + + [mac] Timestamp parameter to requestAnimationFrame is busted in USE(REQUEST_ANIMATION_FRAME_TIMER) path + https://bugs.webkit.org/show_bug.cgi?id=68769 + + Reviewed by Simon Fraser. + + Convert the time parameter from double to DOMTimeStamp using convertSecondsToDOMTimeStamp rather than relying on + implicit double->long conversion, which ignores the units of the value. + + Test: fast/animation/request-animation-frame-timestamps-advance.html + + * dom/ScriptedAnimationController.cpp: + (WebCore::ScriptedAnimationController::animationTimerFired): + +2011-09-09 Chris Marrin <cmarrin@apple.com> + + requestAnimationFrame doesn't throttle on Mac + https://bugs.webkit.org/show_bug.cgi?id=67171 + + Reviewed by Simon Fraser. + + Changed requestAnimationFrame to use a Timer in ScriptedAnimationController + on Mac, rather than runLoopObservers. The Timer is throttled to fire no + faster than every 15ms. It is behind a WTF_USE_REQUEST_ANIMATION_FRAME_TIMER + flag and can be used by any implementation, but currently it is only enabled + by PLATFORM(MAC). + + * dom/ScriptedAnimationController.cpp: + (WebCore::ScriptedAnimationController::ScriptedAnimationController): + (WebCore::ScriptedAnimationController::resume): + (WebCore::ScriptedAnimationController::registerCallback): + (WebCore::ScriptedAnimationController::serviceScriptedAnimations): + (WebCore::ScriptedAnimationController::scheduleAnimation): + (WebCore::ScriptedAnimationController::animationTimerFired): + * dom/ScriptedAnimationController.h: + * loader/EmptyClients.h: + * page/Chrome.cpp: + (WebCore::Chrome::scheduleAnimation): + * page/ChromeClient.h: + +2011-05-11 Antoine Labour <piman@chromium.org> Reviewed by David Levin. Expose shouldBufferData to ThreadableLoaderOptions to be able to disable buffering of the |