Document: Use a DeferrableOneShotTimer to throw out StyleResolver when unused.
<http://webkit.org/b/115929>

Reviewed by Anders Carlsson.

Nothing exciting here, just replacing a rickety-looking punting mechanism with a proper
DeferrableOneShotTimer. Note that the timeout changes from 60 to 30 seconds because DOST
works by punting a full interval on next timeout.

* dom/Document.cpp:
(WebCore::Document::Document):
(WebCore::Document::didAccessStyleResolver):
(WebCore::Document::styleResolverThrowawayTimerFired):
* dom/Document.h:
(Document):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150013 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[texmap][GStreamer] Composited Video support
https://bugs.webkit.org/show_bug.cgi?id=86410

Patch by Víctor Manuel Jáquez Leal <vjaquez@igalia.com> on 2013-05-13
Reviewed by Philippe Normand.

Enable the video accelerated compositing using the WebKit's
TextureMapper.

This patch does not use hardware accelerated video decoding. It
provides a generic path for system memory buffers.

No new tests, already covered by existing tests.

* platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp:
(WebCore::MediaPlayerPrivateGStreamerBase::MediaPlayerPrivateGStreamerBase):
(WebCore):
(WebCore::MediaPlayerPrivateGStreamerBase::updateTexture): update the
texture content with the new received video buffer.
(WebCore::MediaPlayerPrivateGStreamerBase::triggerRepaint): choose to
use the accelerated compositing or the normal code path
(WebCore::MediaPlayerPrivateGStreamerBase::paint): if accelerated
compositing is used this method is halted.
(WebCore::MediaPlayerPrivateGStreamerBase::paintToTextureMapper): get
a texture from the pool and draws it if it is already available.
* platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.h:
(MediaPlayerPrivateGStreamerBase):
(WebCore::MediaPlayerPrivateGStreamerBase::platformLayer): returns itself
(WebCore::MediaPlayerPrivateGStreamerBase::supportsAcceleratedRendering):
returns true

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150014 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CoordGfx] requestAnimationFrame performance issues
https://bugs.webkit.org/show_bug.cgi?id=112345

Patch by Noam Rosenthal <noam@webkit.org> on 2013-05-13
Reviewed by Jocelyn Turcotte.

Source/WebCore:

Removed current requestAnimationFrame logic from CoordinatedGraphics. The new logic
is entirely in WebKit2 CoordinatedLayerTreeHost.

Covered by existing tests in fast/animations.

* platform/graphics/texmap/coordinated/CoordinatedGraphicsScene.cpp:
(WebCore::CoordinatedGraphicsScene::CoordinatedGraphicsScene):
(WebCore::CoordinatedGraphicsScene::paintToCurrentGLContext):
* platform/graphics/texmap/coordinated/CoordinatedGraphicsScene.h:
(CoordinatedGraphicsScene):

Source/WebKit2:

Changed the logic of requestAnimationFrame in Coordinated Graphics.
We don't send any IPC messages for requestAnimationFrame. Instead, we do one of two things:
- If there is already a frame pending in the UI process, do nothing, as the animations would
  be serviced when the frame is returned to the web process.
- If there is no frame pending, we schedule a flush, making sure that that flush occurs at
  least 1/60 seconds after the last animation service, so that we don't get an infinite loop
  of flushes.

* UIProcess/CoordinatedGraphics/CoordinatedLayerTreeHostProxy.cpp:
(WebKit::CoordinatedLayerTreeHostProxy::requestAnimationFrame):
* UIProcess/CoordinatedGraphics/CoordinatedLayerTreeHostProxy.h:
* WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:
(WebKit::CoordinatedLayerTreeHost::CoordinatedLayerTreeHost):
(WebKit::CoordinatedLayerTreeHost::flushPendingLayerChanges):
(WebKit::CoordinatedLayerTreeHost::scheduleAnimation):
* WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.h:
* WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.messages.in:

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