| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This only move files without adjusting any paths.
This moves:
- lib/quick -> src/webengine/api (API files)
lib/quick -> src/webengine (other files)
This contains the main QtWebEngine module library since
<ec7b2ee70a8b2db7fb87f50671a001ddd54697b0>.
- lib/widgets -> src/webenginewidgets
Also rename this directory to match its module name and rename Api to api.
- lib -> src/core
- process -> src/process
- resources -> src/core/resources
- tools/* -> tools/scripts/
The build directory is spread as follow:
- build/build.pro -> src/core/gyp_run.pro
- build/qmake_extras/* -> src/core/ (for the host and target .pro files)
- build/qmake -> tools/qmake
- Build related scripts -> tools/buildscripts
Change-Id: I0cded1de772c99c0c1da6536c9afea353236b4a1
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A few changes are necessary to allow fetching textures provided by
the render processes through IPC and bound to their respective GL
context in the GPU process and use them in the QtQuick scene graph.
- Remove the plain color test textures.
- Allow setting the QtQuick QOpenGLContext's handle as the share
context for all context set as shared in the Chromium GPU process.
We do this by letting the GpuChannelManager ask us for a
ShareGroup instance responsible for returning a sharing GL context
handle.
- Fetch texture IDs from the MailboxManager used by the GPU process
using the Mailbox given to us in the DelegatedFrameData.
This is the same mechanism used by Chromium to share textures
between "client" GL contexts.
- Keep the QtQuick scene graph threads and Chromium in-process GPU
thread separate. The complicated part of merging those two
rendering pipelines on the same thread is that it would force Qt
to also use only one thread for rendering. For the moment we will
try to synchronize those threads together instead.
- Lock the Qt SG thread while waiting for resource sync points.
Do so by posting a callback to the Chromium GPU thread and wait
until the sync point of every resource has been retired by the
producing contexts.
- Acknowledge the delegated from once QtQuick swapped the GL buffers
instead of right after we added the frame to the scene graph.
This fixes some issues where the textures for the previous frame
would already be released as Chromium was producing the new frame.
There are still a few issues regarding synchronization that have to
be fixed, especially when Qt triggers the rendering of a new frame
while Chromium is starting to produce the next frame.
Note: To enable it we still need to pass the following command switches:
--enable-delegated-renderer --enable-threaded-compositing --in-process-gpu
Change-Id: I2d4f7fac603b1808ed1495a8d689cb48e9ed41b9
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RenderWidgetHostViewQtDelegate acts as a bidirectional interface to
avoid exporting Chromium symbols outside of the core dynamic library.
The problem is that, other than this, from the top layer point of
view, its responsibilities are the same as RenderWidgetHostViewQt,
and it would be better not to split its logic without properly
defined responsibilities.
Using it as a base class and interfacing through its protected
methods is also cumbersome and make the destination of calls on the
upper layer difficult to discern.
Use instead a dual pure interface mechanism like WebContentsAdapter
and pass the callback client interface directly in
WebContentsAdapterClient::CreateRenderWidgetHostViewQtDelegate.
This allows RenderWidgetHostViewQtDelegate to be solely what it
should be, an interface.
Change-Id: I4e55439ae7f9539cc9e360f0756fbf391405f3b7
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This provides a stub implementation that renders quads and RenderPasses
using QSGNodes in QQuickWebEngineView.
The BackingStore code path is still supported when the delegated renderer
switch is not enabled. To use the new rendering, pass the following switches:
--enable-delegated-renderer --enable-threaded-compositing
This uses debug, plain color textures until we can fetch tiles and
textures from the ResourceProvider across OpenGL context boundaries.
Change-Id: I33ea0738dc5a326ef79c1435f75c044c42e8551f
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
| |
|
|
|
|
|
|
|
|
| |
This prepares the addition of a delegated renderer implementation
for the QtQuick view.
Use a template for the base class since the accelerated delegate
will derive from QQuickItem instead of QQuickPaintedItem.
Change-Id: I5619290c0023bafdd27f18dab9edc10f5fbbf838
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
| |
|
|
|
|
|
|
|
|
| |
Since the QWindow returned by the RWHV delegates was always 0 we never
actually propagated a valid WebScreenInfo to chromium.
Additionally the painting and scrolling in the backing store had to be
fixed so that the device pixel ratio is taken into account.
Change-Id: I22dc135e8e090362201292863ed911464b9fc133
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
| |
|
|
|
| |
Change-Id: I58d83f4f33728f92e4bf13b6be30b15528fdd033
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
| |
|
|
|
|
|
|
| |
This avoids the RWHV being accessed before being attached to
the delegate when attaching the later to the view's layout.
Change-Id: I5fffef60fdd7203cfb4ced807b5475aac676ea09
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As this looks like a layering violation.
Instead, rely on WebContentsViewImpl::CreateRenderViewForRenderManager
querying the WebContentsView's size before setting it on the
RenderWidgetHostView. The WebContentsView now gets the size of the
actual view through the Adapter interface.
Then, in RenderWidgetHostViewQt, we now forward the resize request
to the delegate.
Change-Id: Ide679f6d114508cc7c9ffac83daad19d16764a4d
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
| |
|
|
|
| |
Change-Id: Ic08f83db03454542554fac9e590d79a4440a4b28
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
| |
|
|
|
| |
Change-Id: I5ce13af04de8520bb0ab93c48a2493822aa42294
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
Only enable it when the --force-compositing-mode switch is
used. The purpose of this is only to allow testing pinch-zooming
until we are able to use the delegated renderer in the QtQuick view.
Change-Id: I2ca265c84c8fe6a74299f1b2757ad525f33fae17
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
|
|
This is the first step to making proper Qt Modules out of QtWebEngine.
The Widgets integration becomes a proper C++ Qt Module while we make
the QtQuick side a QML plugin for now (could probably be promoted if
the need arises).
Code-wise, this means the introduction of a WebContentsAdapterClient
interface that is subclassed by the private implementation of our API
classes for delegation of things that are UI specific. Functionality
from WebContents and the like is exposed via the WebContentsAdapter.
Change-Id: I4ca3395b9fe8502a24e36002cfd5af44067bb6e8
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
