DFG cell checks should be hoisted
https://bugs.webkit.org/show_bug.cgi?id=91717

Reviewed by Geoffrey Garen.

The DFG has always had the policy of hoisting array and integer checks to
the point of variable assignment. Eventually, we added doubles and booleans
to the mix. But cells should really be part of this as well, particularly
for 32-bit where accessing a known-type variable is dramatically cheaper
than accessing a variable whose types is only predicted but otherwise
unproven.
        
This appears to be a definite speed-up for V8 on 32-bit, a possible speed-up
for Kraken, and a possible slow-down for V8 on 64-bit (around 0.2% if at
all). Any slow-downs can, and should, be addressed by making the hoisting
logic cognizant of variables that are never used in a manner that requires
type checks, and by sinking argument checks to the point(s) of first use.
        
To make this work I had to change some OSR machinery, and special-case the
type predictions of the 'this' argument for constructors. OSR exit normally
assumes that arguments are boxed, which happens to be true because the
type prediction used for check hoisting is LUB'd with the type of the
argument that was passed in - so either the arguments are always stored to
with the full tag+payload, or if only the payload is stored then the tag
matches whatever the caller would have set. But not so with the 'this'
argument for constructors, which is not initialized by the caller. We
could make this more precise by having argument types for OSR be inferred
using similar machinery to other locals, but I figured that for this patch
I should use the surgical fix.

* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::branchTestPtr):
(MacroAssemblerX86_64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::testq_rm):
(X86Assembler):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::initialize):
(JSC::DFG::AbstractState::execute):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::isCreatedThisArgument):
(Graph):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArgumentTypes):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValueSource.h:
(JSC::DFG::ValueSource::forSpeculation):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123169 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Fix build break because of changing parameter type of
vibration virtual function on EFL port.

* WebProcess/WebCoreSupport/WebVibrationClient.cpp:
(WebKit::WebVibrationClient::vibrate):
* WebProcess/WebCoreSupport/WebVibrationClient.h:
(WebVibrationClient):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123170 268f45cc-cd09-0410-ab3c-d52691b4dbfc
SVG images broken when max-width specified.
https://bugs.webkit.org/show_bug.cgi?id=91474

Source/WebCore: 

SVG images were computing intrinsic dimensions when width and height were auto that did not
respect min-max width/height. Normal images had code that applied these constraints properly.
Looking at the code before the check-in that broke things, these constraints used to be
applied to all images regardless of type via calcAspectRatioLogicalWidth/Height.
        
This patch leaves the new function structure in place but converts the code to be more like
it was prior to the introduction of the regression. Instead of raw intrinsic sizes being
used in the SVG case, now all image types get the intrinsic sizes constrained when doing
width/height computations.

Reviewed by Dan Bernstein.

Test: svg/as-image/svg-intrinsic-size.html

* rendering/RenderReplaced.cpp:
(WebCore::RenderReplaced::computeAspectRatioInformationForRenderBox):
Rename computeIntrinsicRatioInformationForRenderBox to computeAspectRatioInformationForRenderBox.
Also rename the intrinsicSize reference to constrainedSize to reflect the fact that the size
is not necessarily the intrinsic size any longer but instead a size where both axes have been
constrained based off the max-min values of the opposite axes.
        
Move the constraining code out of RenderReplaced::computeIntrinsicRatioInformation into this
function so that the SVG code path appies the constraints as well. The movement of this code
is what fixes the bug.

(WebCore::RenderReplaced::computeIntrinsicRatioInformation):
Changed to remove the code that constrains the returned size, since it is shifting to
computeAspectRatioInformationForRenderBox instead.

(WebCore::RenderReplaced::computeReplacedLogicalWidth):
(WebCore::RenderReplaced::computeReplacedLogicalHeight):
* rendering/RenderReplaced.h:
(RenderReplaced):
Patch the name of the reference passed in to computeReplacedLogicalWidth/Height to be
constrainedSize instead of intrinsicSize, so that it is more obvious that the returned
result is not just the intrinsic size of the image.

LayoutTests: 

Reviewed by Dan Bernstein.

* svg/as-image/svg-intrinsic-size-expected.html: Added.
* svg/as-image/svg-intrinsic-size.html: Added.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123171 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Suspend when there's no target buffer until an external compositor is set
https://bugs.webkit.org/show_bug.cgi?id=91686
RIM PR 174365

Reviewed by Antonio Gomes.

If we don't have a client window (i.e. rendering to
GL directly) and a WebPageCompositor is only set
after a rendering operation, then we'll try to render
to BackingStorePrivate::buffer() which doesn't exist
at this point. That's bad, and gets us various
assertions and possibly worse.

Fix it by starting in a screen-suspended state and only
resuming screen and backingstore once a compositor is
actually set.

So, in effect, with this patch applied, the sequence
of events will look like this:

1) WebPage & BackingStore are initialize, neither window
   nor compositor exists, therefore buffer() returns 0.
   createSurface() therefore suspends screen and
   backingstore.
2) loadURL() or loadData() is called, web page is
   fully loaded, however we don't try to render because
   we're still suspended, still have no target buffer.
3) A WebPageCompositor is being set from outside.
   At the beginning of WebPage::setCompositor() we still
   don't have a buffer() so there's nothing to suspend,
   however, after the sync call to setCompositorHelper()
   the compositor is set so buffer() will return a
   nonzero value, causing us to resume at this point.

Using the existence of a target buffer to determine
whether or not to enable rendering or keep it suspended
seems like a good idea, and the implementation (while
not quite perfect yet) is a step forward from before.

* Api/BackingStore.cpp:
(BlackBerry::WebKit::BackingStorePrivate::createSurfaces):
* Api/WebPage.cpp:
(BlackBerry::WebKit::WebPagePrivate::setCompositor):
(BlackBerry::WebKit::WebPagePrivate::setCompositorHelper):
* Api/WebPage_p.h:
(WebPagePrivate):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123172 268f45cc-cd09-0410-ab3c-d52691b4dbfc
webkitpy: executive_unittest still failing when run in parallel
https://bugs.webkit.org/show_bug.cgi?id=91795

Reviewed by Adam Barth.

It turns out that test_kill_process and test_kill_all are both
launching the same process, and so if they're run at the same
time, test_kill_all interferes w/ test_kill_process.

Merging the two tests solves the issue :).

* Scripts/webkitpy/common/system/executive_unittest.py:
(ExecutiveTest.test_kill_process):
(ExecutiveTest._assert_windows_image_name):
(ExecutiveTest):
(ExecutiveTest.test_windows_image_name):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123173 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Suppress tests requiring a rebaseline.
Skia roll to 4683 changes gradient rendering, and rebaselines are required.
https://bugs.webkit.org/show_bug.cgi?id=91797

Patch by Jeff Timanus <twiz@chromium.org> on 2012-07-19
Reviewed by Kenneth Russell.

* platform/chromium/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123174 268f45cc-cd09-0410-ab3c-d52691b4dbfc
enable Web Audio for chromium android port
https://bugs.webkit.org/show_bug.cgi?id=89428

Patch by Wei James <james.wei@intel.com> on 2012-07-19
Reviewed by Kenneth Russell.

Source/WebCore:

* WebCore.gyp/WebCore.gyp:
* platform/audio/FFTFrameStub.cpp:
(WebCore::FFTFrame::doFFT):

Source/WebKit/chromium:

* features.gypi:

Source/WTF:

* wtf/MathExtras.h:
(log2):
(log2f):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123175 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Enable CSS variables compile time flag in Chrome.
https://bugs.webkit.org/show_bug.cgi?id=91708

Reviewed by Dimitri Glazkov.

Flips the ENABLE_CSS_VARIABLES compile flag on for Chrome. There is also a run-time flag that is off by default,
so this should not have a user visible effect other than making the variables runtime flag visible at chrome://flags/

* features.gypi:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@123176 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] [WK2] Add methods to get/set a custom text encoding
https://bugs.webkit.org/show_bug.cgi?id=90604

Patch by Sudarsana Nagineni <sudarsana.nagineni@linux.intel.com> on 2012-07-19
Reviewed by Kenneth Rohde Christiansen.

Source/WebKit2:

Add methods to get/set custom character encoding.

* UIProcess/API/efl/ewk_view.cpp:
(_Ewk_View_Private_Data):
(_ewk_view_priv_del):
(ewk_view_setting_encoding_custom_get):
(ewk_view_setting_encoding_custom_set):
* UIProcess/API/efl/ewk_view.h:

Tools:

Added support for setting custom character encoding in MiniBrowser.
Use 'F3' to set the custom character encoding.

* MiniBrowser/efl/main.c:
(on_key_down):

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