Out-of-process plug-ins should support asynchronous initialization
<rdar://problem/10598594> and https://bugs.webkit.org/show_bug.cgi?id=92919

Reviewed by Anders Carlsson.

Source/WebKit2:

If a plug-in has been deemed capable of asynchronous initialization when run out of process...
...then do that!

Add flags to communicate that this plugin create is meant to create a plug-in already requested asynchronously and
to include whether or not the initialize call should include an artificial delay (for testing):
* PluginProcess/PluginCreationParameters.cpp:
(WebKit::PluginCreationParameters::PluginCreationParameters):
(WebKit::PluginCreationParameters::encode):
(WebKit::PluginCreationParameters::decode):
* PluginProcess/PluginCreationParameters.h:
(PluginCreationParameters):

Add a flag for the UI Process to tell the PluginProcess that it supports asynchronous initialization:
* Shared/Plugins/PluginProcessCreationParameters.cpp:
(WebKit::PluginProcessCreationParameters::PluginProcessCreationParameters):
(WebKit::PluginProcessCreationParameters::encode):
(WebKit::PluginProcessCreationParameters::decode):
* Shared/Plugins/PluginProcessCreationParameters.h:
(PluginProcessCreationParameters):

Allow the UI Process to pass along whether the plug-on supports asynchronous initialization:
* UIProcess/Plugins/PluginProcessProxy.cpp:
(WebKit::PluginProcessProxy::pluginProcessCrashedOrFailedToLaunch):
(WebKit::PluginProcessProxy::didCreateWebProcessConnection):
* UIProcess/Plugins/PluginProcessProxy.h:
(PluginProcessProxy):
* UIProcess/Plugins/mac/PluginProcessProxyMac.mm:
(WebKit::PluginProcessProxy::platformInitializePluginProcess):
* UIProcess/WebProcessProxy.messages.in:

Allow the Plugin Process to pass whether or not it supports asynchronous initialization, originally determined
in the UI Process, along to the WebProcess:
* PluginProcess/PluginProcess.cpp:
(WebKit::PluginProcess::PluginProcess):
(WebKit::PluginProcess::initializePluginProcess):
(WebKit::PluginProcess::createWebProcessConnection):
* PluginProcess/PluginProcess.h:
(PluginProcess):
* UIProcess/Plugins/PluginProcessProxy.messages.in:

Add a flag so PluginProcessConnections remember whether or not they support asynchronous initialization:
* WebProcess/Plugins/PluginProcessConnection.cpp:
(WebKit::PluginProcessConnection::PluginProcessConnection):
(WebKit::PluginProcessConnection::setSupportsAsynchronousPluginInitialization):
(WebKit):
* WebProcess/Plugins/PluginProcessConnection.h:
(WebKit::PluginProcessConnection::create):
(WebKit::PluginProcessConnection::supportsAsynchronousPluginInitialization):
(PluginProcessConnection):

Create PluginProcessConnections with the flag passed down from the PluginProcess about whether or not they
support asynchronous initialization:
* WebProcess/Plugins/PluginProcessConnectionManager.cpp:
(WebKit::PluginProcessConnectionManager::getPluginProcessConnection):

Responding to messages from the WebProcess, most of the heavy decision making in asynchronous initialization is here:
* PluginProcess/WebProcessConnection.cpp:
(WebKit::asynchronousInstanceIDsToIgnore): A set of instance IDs to *not* create asynchronously later because we know
  we no longer need to.
(WebKit):
(WebKit::WebProcessConnection::didReceiveMessage):
(WebKit::WebProcessConnection::destroyPlugin): If the plug-in doesn't exist but is awaiting asynchronous creation, flag
  this instance ID in the "asynchronous ignore set".
(WebKit::WebProcessConnection::createPluginInternal): Renamed from createPlugin, actually does the plug-in creation.
(WebKit::WebProcessConnection::createPlugin): Adds the instance ID to the "asynchronous ignore set" then calls createPluginInternal.
(WebKit::WebProcessConnection::createPluginAsynchronously): If the instance ID is in the "asynchronous ignore set", remove it from the
  set and do nothing else. Otherwise, perform the initialization and then send the asynchronous result back to the WebProcess.
* PluginProcess/WebProcessConnection.h:
(WebProcessConnection):
* PluginProcess/WebProcessConnection.messages.in:

Add helpers for asynchronous initialization that all plug-in types must implement:
* WebProcess/Plugins/Plugin.h:
(Plugin):

Add helpers for asynchronous initialization that plug-in controllers can override:
* WebProcess/Plugins/PluginController.h:
(PluginController):
(WebKit::PluginController::asynchronousPluginInitializationEnabled):
(WebKit::PluginController::asynchronousPluginInitializationEnabledForAllPlugins):
(WebKit::PluginController::artificialPluginInitializationDelayEnabled):

Give PluginProxys the ability to initialize either asynchronously or synchronously, and also the ability to synchronously
wait for previously asynchronous initialization (in case their PluginScriptObject is required):
* WebProcess/Plugins/PluginProxy.cpp:
(WebKit::PluginProxy::PluginProxy):
(WebKit::PluginProxy::initialize): Store the plugin creation parameters as a member, and decide whether to try synchronous
  or asynchronous initialization.
(WebKit):
(WebKit::PluginProxy::canInitializeAsynchronously): Answer based on preferences and what the PluginProcessConnection says
  that it supports.
(WebKit::PluginProxy::waitForAsynchronousInitialization): Synchronously wait on initialization when asynchronous initialization
  was previously requested.
(WebKit::PluginProxy::initializeSynchronously):
(WebKit::PluginProxy::didCreatePlugin): Double-check that we're still expecting asynchronous initialization, then call
  through to didCreatePluginInternal.
(WebKit::PluginProxy::didCreatePluginInternal): Handle completion of initialization (both synchronously and asynchronously)
(WebKit::PluginProxy::didFailToCreatePlugin): Double-check that we're still expecting asynchronous initialization, then call
  through to didFailToCreatePluginInternal.
(WebKit::PluginProxy::didFailToCreatePluginInternal): Handle failure to initialize (both synchronously and asynchronously)
(WebKit::PluginProxy::destroy):
* WebProcess/Plugins/PluginProxy.h:
(WebKit):
(WebKit::PluginProxy::isInitializingAsynchronously):
(PluginProxy):
* WebProcess/Plugins/PluginProxy.messages.in:

* WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::PluginView):
(WebKit::PluginView::~PluginView): Always destroy the plug-in even if it hasn't been initialized yet, as it might be initializing
  right now.
(WebKit::PluginView::initializePlugin): Don't handle the result of initialization immediately. Break that out in to two
  methods that will be called later.
(WebKit):
(WebKit::PluginView::didFailToInitializePlugin):
(WebKit::PluginView::didInitializePlugin):
(WebKit::PluginView::scriptObject): If we truly need the script object, then wait for a synchronous initialization of the plug-in.
(WebKit::PluginView::asynchronousPluginInitializationEnabled):
(WebKit::PluginView::asynchronousPluginInitializationEnabledForAllPlugins):
(WebKit::PluginView::artificialPluginInitializationDelayEnabled):
* WebProcess/Plugins/PluginView.h:
(PluginView):

These methods shouldn't be called in the PluginProcess, only in the WebProcess:
* PluginProcess/PluginControllerProxy.cpp:
(WebKit::PluginControllerProxy::didInitializePlugin):
(WebKit):
(WebKit::PluginControllerProxy::didFailToInitializePlugin):
* PluginProcess/PluginControllerProxy.h:
(PluginControllerProxy):

NetscapePlugin is for in-process plug-ins:
* WebProcess/Plugins/Netscape/NetscapePlugin.h:
(NetscapePlugin):
(WebKit::NetscapePlugin::waitForAsynchronousInitialization):
(WebKit::NetscapePlugin::isInitializingAsynchronously):

Built-in PDFView is currently only in-process:
* WebProcess/Plugins/PDF/BuiltInPDFView.h:
(BuiltInPDFView):
(WebKit::BuiltInPDFView::waitForAsynchronousInitialization):
(WebKit::BuiltInPDFView::isInitializingAsynchronously):

Tools:

Add a plug-in with an NPP_New that takes 550ms (a reasonable trade-off between a solid test and a slow running test)
for testing asynchronous plug-in initialization.

* DumpRenderTree/DumpRenderTree.xcodeproj/project.pbxproj:
* DumpRenderTree/TestNetscapePlugIn/Tests/SlowNPPNew.cpp: Copied from Source/WebKit2/Shared/Plugins/PluginProcessCreationParameters.h.
(SlowNPPNew):
(SlowNPPNew::SlowNPPNew):
(SlowNPPNew::NPP_New):

LayoutTests:

Add tests to make sure a plug-in with a long running NPP_New does not block the web thread.

* platform/mac-wk2/plugins/slow/asynchronous-plugin-initialization-expected.txt: Added.
* platform/mac-wk2/plugins/slow/asynchronous-plugin-initialization-multiple-expected.txt: Added.
* platform/mac-wk2/plugins/slow/asynchronous-plugin-initialization-multiple.html: Added.
* platform/mac-wk2/plugins/slow/asynchronous-plugin-initialization.html: Added.
* platform/mac-wk2/plugins/slow/resources/asynchronous-plugin-initialization-multiple-finish.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124815 268f45cc-cd09-0410-ab3c-d52691b4dbfc
GraphicsLayerAnimation shouldn't use HashMap<String>
https://bugs.webkit.org/show_bug.cgi?id=93284

Reviewed by Kenneth Rohde Christiansen.

Source/WebCore:

Use a vector containing all the animations instead of a map of String to Vector.
The HashMap contains very few elements, which makes it inefficient relatively to a vector.
This has been shown to be a bottleneck in valgrind.

Covered by existing animation tests.

* platform/graphics/GraphicsLayerAnimation.cpp:
(WebCore::GraphicsLayerAnimation::GraphicsLayerAnimation):
(WebCore::GraphicsLayerAnimations::hasActiveAnimationsOfType):
(WebCore::GraphicsLayerAnimations::hasRunningAnimations):
(WebCore::GraphicsLayerAnimations::add):
(WebCore::GraphicsLayerAnimations::pause):
(WebCore::GraphicsLayerAnimations::remove):
(WebCore::GraphicsLayerAnimations::apply):
* platform/graphics/GraphicsLayerAnimation.h:
(GraphicsLayerAnimation):
(WebCore::GraphicsLayerAnimation::name):
(GraphicsLayerAnimations):
* platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:
(WebCore::GraphicsLayerTextureMapper::addAnimation):

Source/WebKit2:

Apply the changes to GraphicsLayerAnimation API.

* WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.cpp:
(WebCore::CoordinatedGraphicsLayer::addAnimation):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124816 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unify JSC date and time formating functions
https://bugs.webkit.org/show_bug.cgi?id=92282

Reviewed by Geoffrey Garen.

Replace the existing functions for formating GregorianDateTime
with one single function. This removes some code duplications
in DatePrototype and is a preperation to fix encoding issues,
since we can add UChar* values to the resulting string now.

* runtime/DateConstructor.cpp:
(JSC::callDate):
* runtime/DateConversion.cpp:
(JSC::formatDateTime):
* runtime/DateConversion.h:
(JSC):
* runtime/DatePrototype.cpp:
(JSC::formateDateInstance):
(JSC::dateProtoFuncToString):
(JSC::dateProtoFuncToUTCString):
(JSC::dateProtoFuncToDateString):
(JSC::dateProtoFuncToTimeString):
(JSC::dateProtoFuncToGMTString):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124817 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Shaders] Parse mix function
https://bugs.webkit.org/show_bug.cgi?id=90101

Patch by Max Vujovic <mvujovic@adobe.com> on 2012-08-06
Reviewed by Dirk Schulze.

Source/WebCore:

Parse the mix function syntax for CSS Shaders as defined in the Filter Effects spec:
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction

The fragment shader argument of the custom filter function can now be a mix function with
the following syntax:
mix(<uri> [ <blend-mode> || <alpha-compositing> ]?)

For example:
-webkit-filter: custom(url(shader.vert) mix(url(shader.frag multiply source-over))

The Filter Effects spec references the Compositing and Blending spec, which defines the
supported blend modes and alpha compositing modes.

Blend modes:
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#blend-mode

This patch adds all of the blend modes in the spec.

Alpha compositing modes:
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#alpha-compositing

This patch does not add any new CSS values for alpha compositing. Currently, we parse the
values that are the same between the spec and the -webkit-background-composite property,
including:
    clear
    copy
    source-over
    source-in
    source-out
    source-atop
    destination-over
    destination-in
    destination-out
    destination-atop
    xor

In the future, we may need to add the following CSS values for alpha compositing:
    lighter
    destination

This is currently under discussion on the www-style mailing list:
http://lists.w3.org/Archives/Public/www-style/2012Aug/0123.html

No new test files. Add test cases in:
    css3/filters/script-tests/custom-filter-property-computed-style.js:
    css3/filters/script-tests/custom-filter-property-parsing-invalid.js:
    css3/filters/script-tests/custom-filter-property-parsing.js:

* GNUmakefile.list.am:
* Target.pri:
* WebCore.gypi:
* WebCore.vcproj/WebCore.vcproj:
* WebCore.xcodeproj/project.pbxproj:
* css/CSSComputedStyleDeclaration.cpp:
(WebCore::CSSComputedStyleDeclaration::valueForFilter):
* css/CSSParser.cpp:
(WebCore::CSSParser::isBlendMode):
(WebCore):
(WebCore::CSSParser::isCompositeOperator):
(WebCore::CSSParser::parseMixFunction):
(WebCore::CSSParser::parseCustomFilter):
* css/CSSParser.h:
(WebCore):
* css/CSSParserValues.h:
(WebCore::CSSParserValueList::currentIndex):
* css/CSSPrimitiveValueMappings.h:
(WebCore::CSSPrimitiveValue::CSSPrimitiveValue):
(WebCore):
(WebCore::CSSPrimitiveValue::operator BlendMode):
* css/CSSValue.cpp:
(WebCore::CSSValue::reportMemoryUsage):
(WebCore::CSSValue::cssText):
(WebCore::CSSValue::destroy):
(WebCore::CSSValue::cloneForCSSOM):
* css/CSSValue.h:
(WebCore::CSSValue::isWebKitCSSMixFunctionValue):
(CSSValue):
* css/CSSValueKeywords.in:
* css/StyleResolver.cpp:
(WebCore::StyleResolver::collectMatchingRulesForList):
* css/WebKitCSSMixFunctionValue.cpp: Added.
(WebCore):
(WebCore::WebKitCSSMixFunctionValue::WebKitCSSMixFunctionValue):
(WebCore::WebKitCSSMixFunctionValue::customCssText):
(WebCore::WebKitCSSMixFunctionValue::cloneForCSSOM):
(WebCore::WebKitCSSMixFunctionValue::reportDescendantMemoryUsage):
* css/WebKitCSSMixFunctionValue.h: Added.
(WebCore):
(WebKitCSSMixFunctionValue):
(WebCore::WebKitCSSMixFunctionValue::create):
* platform/graphics/GraphicsTypes.h:
* platform/graphics/filters/CustomFilterProgram.cpp:
(WebCore::CustomFilterProgram::CustomFilterProgram):
* platform/graphics/filters/CustomFilterProgram.h:
(WebCore::CustomFilterProgramMixSettings::CustomFilterProgramMixSettings):
(CustomFilterProgramMixSettings):
(WebCore):
* rendering/style/StyleCustomFilterProgram.h:
(WebCore::StyleCustomFilterProgram::create):
(WebCore::StyleCustomFilterProgram::StyleCustomFilterProgram):

LayoutTests:

Add tests for custom filter mix function parsing as defined in the Filter Effects spec:
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction

Remove some mac-wk2 and chromium expectations because they are the same as the general
expectations.

* css3/filters/custom/custom-filter-property-computed-style-expected.txt:
* css3/filters/custom/custom-filter-property-parsing-expected.txt:
* css3/filters/custom/custom-filter-property-parsing-invalid-expected.txt:
* css3/filters/script-tests/custom-filter-property-computed-style.js:
* css3/filters/script-tests/custom-filter-property-parsing-invalid.js:
* css3/filters/script-tests/custom-filter-property-parsing.js:
* platform/chromium/css3/filters/custom/custom-filter-property-computed-style-expected.txt:
* platform/chromium/css3/filters/custom/custom-filter-property-parsing-expected.txt:
* platform/chromium/css3/filters/custom/custom-filter-property-parsing-invalid-expected.txt: Removed.
* platform/mac-wk2/css3/filters/custom/custom-filter-property-computed-style-expected.txt: Removed.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124820 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WIN] Remove dependency on pthread from MachineStackMarker
https://bugs.webkit.org/show_bug.cgi?id=68429

Reviewed by Geoffrey Garen.

Windows has no support for calling a destructor for thread specific data.
Since we need more control over creating and deleting thread specific keys
we can not simply extend WTF::ThreadSpecific with this functionality.

All thread specific keys created via the new API get stored in a list.
After a thread function finished we iterate over this list and call
the registered destructor for every item if needed.

Source/JavaScriptCore:

* heap/MachineStackMarker.cpp:  Use the new functions instead of pthread directly.
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::makeUsableFromMultipleThreads):
(JSC::MachineThreads::addCurrentThread):
* heap/MachineStackMarker.h:
(MachineThreads):

Source/WTF:

* wtf/ThreadSpecific.h:
(WTF):
(WTF::threadSpecificKeyCreate): Added wrapper around pthread_key_create.
(WTF::threadSpecificKeyDelete): Added wrapper around pthread_key_delete.
(WTF::threadSpecificSet): Added wrapper around pthread_setspecific.
(WTF::threadSpecificGet): Added wrapper around pthread_getspecific.
* wtf/ThreadSpecificWin.cpp:


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