https://bugs.webkit.org/show_bug.cgi?id=112236

Reviewed by Rob Buis.

PR 232752

Source/WebCore:

The LayerCompositingThread can now position the video window using
either document or window coordinates.

The LayerRenderer class gets a new client interface. This allows us to
avoid state duplication by delegating decisions directly to the client,
which can then be in charge of the (one and only) state.

The context is moved over to the client, as well as delegation of the
decision on whether to clear the surface every frame.

Also, the decision on which coordinate system to use for positioning
child windows is delegated to the client interface.

No new tests, not testable using DRT.

* platform/graphics/blackberry/LayerCompositingThread.cpp:
(WebCore::LayerCompositingThread::drawTextures):
* platform/graphics/blackberry/LayerRenderer.cpp:
(WebCore::LayerRenderer::create):
(WebCore::LayerRenderer::LayerRenderer):
(WebCore::LayerRenderer::setViewport):
(WebCore::LayerRenderer::compositeLayers):
(WebCore::LayerRenderer::toWebKitWindowCoordinates):
(WebCore::LayerRenderer::makeContextCurrent):
* platform/graphics/blackberry/LayerRenderer.h:
(WebCore):
(LayerRenderer):
(WebCore::LayerRenderer::client):
* platform/graphics/blackberry/LayerRendererClient.h: Added.
(Graphics):
(WebCore):
(LayerRendererClient):
(WebCore::LayerRendererClient::~LayerRendererClient):

Source/WebKit/blackberry:

Child windows used to always be positioned in document coordinates,
which requires the
BlackBerry::Platform::Graphics::Window::virtualRect() of the parent
window to be kept in sync with the document visible content rect.
This is easy if there's a one-to-one correspondence between windows
and scrollable frames.

However, for an embedder that can display an entire scene graph (where
the web page is just one of the nodes) in one window, several
scrollable nodes may be present in that window, and it's difficult to
know which scrollable node to sync the virtualRect with. It could also
lead to conflicts, if two scrollable nodes have child windows.

For the latter scenario, it makes more sense to use window coordinates
to place child windows.

The internal default is to use document coordinates, for legacy
reasons.

When an external WebPageCompositor is attached, we switch to using
window coordinates instead of document coordinates by default. The
behavior is still configurable using the new public
setChildWindowPlacement method.

* Api/WebPageCompositor.cpp:
(BlackBerry::WebKit::WebPageCompositorPrivate::WebPageCompositorPrivate):
(BlackBerry::WebKit::WebPageCompositorPrivate::setContext):
(BlackBerry::WebKit::WebPageCompositorPrivate::prepareFrame):
(BlackBerry::WebKit::WebPageCompositorPrivate::render):
(BlackBerry::WebKit::WebPageCompositorPrivate::drawLayers):
(BlackBerry::WebKit::WebPageCompositorPrivate::shouldClearSurfaceBeforeCompositing):
(WebKit):
(BlackBerry::WebKit::WebPageCompositorPrivate::shouldChildWindowsUseDocumentCoordinates):
(BlackBerry::WebKit::WebPageCompositor::WebPageCompositor):
(BlackBerry::WebKit::WebPageCompositor::setChildWindowPlacement):
* Api/WebPageCompositor.h:
* Api/WebPageCompositor_p.h:
(BlackBerry::WebKit::WebPageCompositorPrivate::setChildWindowPlacement):
(WebPageCompositorPrivate):


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