Delegated renderer: Fix remaining synchronization issues.

This fixes two issues:
- The onFrameSwapped slot was connected with a QueuedConnection, this
  means that any previous frame triggered by Qt could be queued right
  before updatePaintNode is called, and be handled right after, thus
  picking our m_pendingAckFrameData and sending the Ack before this
  frame was actually swapped.
- For cases where Qt triggers a new frame (e.g. typing text in a
  QtQuick text area) it would be possible that it starts rendering
  before m_pendingUpdateFrameData had been set, which would render
  the old frame while Chromium might be in the middle of rendering
  the new one on the same resources, or destroying them.

The solution is grossly to do proper used resource reporting to the
child compositors via cc::CompositorFrameAck::resources.
We previously released all resources on every frame, and Chromium
would resend back to us the ones that could be reused without change.
We now instead only return unused resources, but this also means that
we have to keep track of used resources ourselves.
cc::DelegatedFrameData::resource_list only contain new resources to
be added to the scene and we keep a deep copy of the
cc::TransferableResource into our MailboxTextures.

A few other changes that come with this:
- A few null-checks can now be removed since we can better rely on
  the integrity of the information passed through DelegatedFrameData.
- Since we can now prevent used resources from being destroyed while
  we use them, trigger a frame Ack immediately after updatePaintNode
  instead of waiting until the buffer is swapped, like ui::Compositor
  does.
- MailboxTexture is now more autonomous, but still require some
  information from quads. Mark them as not containing alpha by default
  and fetch this information from quads when encountered.

Change-Id: Ice235f3a98a179c87eec7fbcb9880e34b0ed1e73
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Delegated renderer: enable by default for QQuickWebView.

This also allows the software code path to be enabled:
- Programmatically by setting this dynamic property on the QCoreApplication:
  "QQuickWebEngineView_DisableHardwareAcceleration"
- Through the Chromium command line switch "--disable-delegated-renderer"
  for quick development use cases.

Change-Id: I32136d880444e0a24f042c7c4862950b7ed0c910
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Add some QQuickWebView graphics stack tests.

This does basic sanity testing of the graphics stack for both the
hardware accelerated and software codepaths.

This also adds a required signal to report the CompositingSurface later
on if the QWindow wasn't available yet when Chromium asked for it.

Change-Id: I402ec5ade9114c78bea7960c5f0de989f54110e3
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Delegated renderer: implement cc::DrawQuad::SOLID_COLOR.

I could currently only test this with --enable-overlay-scrollbars.

Background color quads still need some work in Chromium to be able to
to use this kind of quads, see
<http://code.google.com/p/chromium/issues/detail?id=114658>.

Change-Id: I9c9bdb5c72b91827cfdb7e38e44755c6361a05cf
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Use a QImage instead of QPixmap in BackingStoreQt.

This is mainly to get rid of the warning shown when using QQuickWebEngineView
without delegated rendering with the threaded scene graph render loop:
"QPainter: It is not safe to use drawPixmap() outside the GUI thread"

The main advantage that QPixmap gave us was that QPixmap::scroll is
provided. This patch pulls out some of its implementation to make the
use case work with QImage.

Since QPixmap is backed by a QImage with the raster paint engine, the
previous behavior should remain except on the DirectFB platform, which
we don't ship to yet.

Change-Id: If77c9079ee95218519be1d092cad24635e29a279
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>