[chromium] Make all compositor screen space transforms operate on content rects
https://bugs.webkit.org/show_bug.cgi?id=91807

Reviewed by Kenneth Russell.

Source/WebCore:

Previously, surface screen space transforms operated on surface
content space but layer screen space transforms operated on layer
space. For the purpose of consistency, unify these two so that they
both operate on content space.

No tests, because no change in behavior expected. Just a refactoring.

* platform/graphics/chromium/LayerChromium.h:
(LayerChromium):
* platform/graphics/chromium/cc/CCDebugRectHistory.cpp:
(WebCore::CCDebugRectHistory::savePaintRects):
(WebCore::CCDebugRectHistory::savePropertyChangedRects):
* platform/graphics/chromium/cc/CCLayerTreeHostCommon.cpp:
(WebCore::calculateDrawTransformsInternal):
(WebCore::CCLayerTreeHostCommon::findLayerThatIsHitByPoint):
* platform/graphics/chromium/cc/CCOcclusionTracker.cpp:
(WebCore::::markOccludedBehindLayer):
(WebCore::::occluded):
(WebCore::::unoccludedContentRect):

Source/WebKit/chromium:

Update tests that deal with screen space transforms to reflect this change.

* tests/CCLayerTreeHostCommonTest.cpp:
* tests/TiledLayerChromiumTest.cpp:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123685 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Move ephemeral data for a single frame in LayerRendererChromium into a structure with a scoped lifetime equal to the frame
https://bugs.webkit.org/show_bug.cgi?id=92294

Reviewed by Adrienne Walker.

The LayerRendererChromium class has a number of member variables that are used
while drawing a single frame. Because they are member variables, their lifetimes
are not clear, and some are even updated between frames, which is not needed.

This change creates a LRC::DrawingFrame structure that holds the data used
while drawing the current frame, and an instance of this structure is held
and passed around to functions in LayerRendererChromium, moving all of the
data out from being member variables on the class to being function
arguments on the relevant methods.

The projection and window matrices are a part of this frame data, and are not
used externally, so they are removed from the CCRenderer interface and included
within the DrawingFrame structure.

Covered by existing tests, no change in behaviour intended.

* platform/graphics/chromium/LayerRendererChromium.cpp:
(WebCore::LayerRendererChromium::LayerRendererChromium):
(WebCore::LayerRendererChromium::viewportChanged):
(WebCore::LayerRendererChromium::clearFramebuffer):
(WebCore::LayerRendererChromium::drawFrame):
(WebCore::LayerRendererChromium::drawRenderPass):
(WebCore::LayerRendererChromium::drawQuad):
(WebCore::LayerRendererChromium::drawCheckerboardQuad):
(WebCore::LayerRendererChromium::drawDebugBorderQuad):
(WebCore::LayerRendererChromium::drawBackgroundFilters):
(WebCore::LayerRendererChromium::drawRenderPassQuad):
(WebCore::LayerRendererChromium::drawSolidColorQuad):
(WebCore::LayerRendererChromium::drawTileQuad):
(WebCore::LayerRendererChromium::drawYUVVideoQuad):
(WebCore::LayerRendererChromium::drawStreamVideoQuad):
(WebCore::LayerRendererChromium::drawTextureQuad):
(WebCore::LayerRendererChromium::drawIOSurfaceQuad):
(WebCore::LayerRendererChromium::finishDrawingFrame):
(WebCore::LayerRendererChromium::drawTexturedQuad):
(WebCore::LayerRendererChromium::copyTextureToFramebuffer):
(WebCore::LayerRendererChromium::isCurrentRenderPass):
(WebCore::LayerRendererChromium::useRenderPass):
(WebCore::LayerRendererChromium::useScopedTexture):
(WebCore::LayerRendererChromium::bindFramebufferToTexture):
(WebCore::LayerRendererChromium::setScissorToRect):
(WebCore::LayerRendererChromium::setDrawFramebufferRect):
* platform/graphics/chromium/LayerRendererChromium.h:
(DrawingFrame):
(WebCore::LayerRendererChromium::DrawingFrame::DrawingFrame):
(LayerRendererChromium):
* platform/graphics/chromium/cc/CCRenderer.h:
(CCRenderer):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123686 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Forms] Move HTMLInputElement::updateInnerTextValue to InputType class
https://bugs.webkit.org/show_bug.cgi?id=92230

Reviewed by Kent Tamura.

This patch moves implementaion of HTMLInputElement::updateInnerTextValue()
into input type classes, removes updateInnerTextValue() from HTMLInputElement,
and updates call site of updateInnerTextValue().

No new tests. This patch doesn't change behavior.

* html/DateInputType.cpp:
(WebCore::DateInputType::handleBlurEvent): Updated call site of updateInnerTextValue().
* html/HTMLInputElement.cpp:
(WebCore::HTMLInputElement::updateType): Updated call site of updateInnerTextValue().
(WebCore::HTMLInputElement::parseAttribute): Updated call site of updateInnerTextValue().
(WebCore::HTMLInputElement::copyNonAttributePropertiesFromElement): Updated call site of updateInnerTextValue().
(WebCore::HTMLInputElement::setSuggestedValue): Updated call site of updateInnerTextValue().
* html/HTMLInputElement.h:
(HTMLInputElement): Removed updateInnerTextValue().
* html/InputType.cpp:
(WebCore::InputType::updateInnerTextValue): Added default implementaion.
* html/InputType.h:
(InputType): Added declaration of updateInnerTextValue().
* html/NumberInputType.cpp:
(WebCore::NumberInputType::handleBlurEvent): Updated call site of updateInnerTextValue().
* html/TextFieldInputType.cpp:
(WebCore::TextFieldInputType::setValue): Updated call site of updateInnerTextValue().
(WebCore::TextFieldInputType::updateInnerTextValue): Moved implementaion from HTMLInputElement.
* html/TextFieldInputType.h:
(TextFieldInputType): Added declaration of updateInnerTextValue().


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123687 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Changes to the WebFrame API cause dependent apps to crash.
https://bugs.webkit.org/show_bug.cgi?id=91656
<rdar://problem/11904605>

Patch by Roger Fong <roger_fong@apple.com> on 2012-07-25
Reviewed by Jon Honeycutt.

Changes to the WebFrame API cause certain apps to crash because of inconsistencies in the COM interface.
The resumeAnimations and suspendAnimations are removed, which are still needed.
The counterValueByElementId method was also removed, although is not needed there.
However, for all of these methods, no method stubs were added where appropriate after removal.

* Interfaces/IWebFramePrivate.idl:
Added resumeAnimations() and suspendAnimations() methods back in. Added unused method stub for counterValueByElementId method.

* WebFrame.cpp:
(WebFrame::resumeAnimations):
Added this method back in.
(WebFrame::suspendAnimations):
Added this method back in.

* WebFrame.h:
(Re)added methods and unused method stubs.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123688 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Initialize QualifiedName's strings from the read only data segment
https://bugs.webkit.org/show_bug.cgi?id=92226

Patch by Benjamin Poulain <bpoulain@apple.com> on 2012-07-25
Reviewed by Anders Carlsson.

Source/WebCore: 

Modify the initialization of static QualifiedName to initialize the AtomicString
with the data from the read only memory.

Overall, HTMLNames::init() gets 10% faster.

* dom/QualifiedName.cpp:
(WebCore::QualifiedName::QualifiedName):
* dom/QualifiedName.h:
(QualifiedName):
Remove the useless constructor taking a char* and get rid of the init() function.
The AtomicString representing the name should be constructed by the caller of QualifiedName.

Because the init() code is relatively large and is only executed once, it is important to
keep the AtomicString construction separate. The function createQualifiedName() was added
to improve the cache use. The short version let us reduce the code one more instruction per
call.

* dom/make_names.pl:
(printQualifiedNameMaker):
(printShortQualifiedNameMaker):
(printNamesCppFile):
(printDefinitions):

Source/WTF: 

Add constructors for StringImpl and AtomicString to be able to create
the strings from the literal in read only memory.

* wtf/text/AtomicString.cpp:
(HashTranslatorCharBuffer):
(WTF::LCharBufferFromLiteralDataTranslator::hash):
(LCharBufferFromLiteralDataTranslator):
(WTF::LCharBufferFromLiteralDataTranslator::equal):
(WTF::LCharBufferFromLiteralDataTranslator::translate):
(WTF::AtomicString::addFromLiteralData):
* wtf/text/AtomicString.h:
(WTF::AtomicString::AtomicString):
(AtomicString):
* wtf/text/StringImpl.cpp:
(WTF::StringImpl::createFromLiteral):
* wtf/text/StringImpl.h:
(WTF):
(StringImpl):
(WTF::StringImpl::createFromLiteral):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123689 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JSC GC object copying APIs should allow for greater flexibility
https://bugs.webkit.org/show_bug.cgi?id=92316

Reviewed by Mark Hahnenberg.

It's now the case that visitChildren() methods can directly pin and allocate in new space during copying.
They can also do the copying and marking themselves. This new API is only used for JSObjects for now.

* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/MarkStack.cpp:
(JSC::SlotVisitor::allocateNewSpaceSlow):
(JSC::SlotVisitor::allocateNewSpaceOrPin):
(JSC):
(JSC::SlotVisitor::copyAndAppend):
* heap/MarkStack.h:
(MarkStack):
(JSC::MarkStack::appendUnbarrieredValue):
(JSC):
* heap/SlotVisitor.h:
* heap/SlotVisitorInlineMethods.h: Added.
(JSC):
(JSC::SlotVisitor::checkIfShouldCopyAndPinOtherwise):
(JSC::SlotVisitor::allocateNewSpace):
* runtime/JSObject.cpp:
(JSC::JSObject::visitOutOfLineStorage):
(JSC):
(JSC::JSObject::visitChildren):
(JSC::JSFinalObject::visitChildren):
* runtime/JSObject.h:
(JSObject):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123690 268f45cc-cd09-0410-ab3c-d52691b4dbfc