| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To implement the Web Inspector we need a delegate to handle the http
server and devtools connections, a landing page, a ContentClient to
tell the devtools server where to find its frontend resources, those
frontend resources, and an API for embedders to turn on inspectability
in WebEngineViews.
The frontend resources are build by the chromium build and are copied
over as part of lib's build.
The landing page was taken directly from content_shell. This
should be replaced by either a new one for all QtWebEngine embedders or
by a mechanism for embedders to supply their own (or both).
Change-Id: Id4076d5ede34a91abf8dba443aed4dca4be1b3e5
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
| |
Changed the header #defines to UPPERCASE_CLASS_NAME_H.
Change-Id: I49dec91d7a97808c1b9618df6d985939fd84babb
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Local file and data url support can simply be added
by registering the appropriate ProtocolHandlers.
Displaying the contents of a directory is slightly
more complex. This requires access to some html
resource files that can be used to list the contents
in rows. For Chromium such resource files are usually
contained in a .pak file which is shipped with the binary.
Since deploying additional files is very complicated for Qt,
we want to use the Qt Resource System to bundle .pak files.
Therefore this patch adds handling of rcc content generated
from a .qrc file to our gyp_generator.prf.
Further it replaces the regular ResourceBundle implementation
with a Qt specific one.
And it also implements a DataPackQt class that allows
using DataPack instances with data from a QByteArray and
therefore from the Qt Resource System.
Change-Id: Ic41e34fbd9aec8596cbc85666a762ecdaa604edc
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
|
|
|
|
|
|
|
| |
Remove code that would only be needed for content_browsertests
that we do not require for now.
Change-Id: I2cabbcfe63bcc0da838462eb97ab8c7eaf7289c7
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
ContentBrowserClientQt is a singleton which makes it possible
to access it from WebContentsViewQt and removes the need for
patching chromium.
This is similar to how ShellContentBrowserClient is managed
in the content shell.
Change-Id: I67f35520935388888c7230806ad543a58b3211c3
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the global factory function content::CreateWebContentsView
is also needed by the web process and we exclude all implementations
we have to place the definition of it in the shared static lib.
However, to prevent the need for moving platform layer classes
back to the shared static lib we have to revert back to use
ContentBrowserClient::OverrideCreateWebContentsView in the API layer
to create our platform WebContentsViewQt and make the global factory
function definition empty.
Change-Id: I9d46524b22458b26a043c80df02b4a5fa7d91a55
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
|
|
|
|
|
|
|
| |
Use the content::CreateWebContentsView factory function to create the
contents view since we already have to implement it.
Change-Id: Ib60cb29604ac84877e154a47ae27f44672284726
Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
|
| |
|
|
|
|
|
|
|
| |
Introduce a few more bits of our own very basic implementations
(URLRequestContextGetter and NetworkDelegate subclasses).
Still need to figure out the appropriate dependancies in blinq.gypi
|
|
|
|
|
|
|
| |
process uses the same code as lib and decides at runtime which
code to run. Fix the debug build by making sure that all infrastructure
code is available in both process and lib by building common code
not shared directly through chromium sources in a separate static lib.
|
|
|
|
|
|
|
|
|
| |
This layers things properly to be able to implement the UI in the
example application instead of directly in shell_qt.cpp.
This is still using global variables to allow the Shell platform
code to do callbacks to the API classes. This should go away once
we properly implemented a WebContentsDelegate.
|
| |
|
|
We now have our own minimalistic subclass, which still makes use of
some shell parts.
|