| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Change-Id: I070e5b5f135f0e74eaf47bd5975892fd288dafab
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
|
| |
|
|
|
| |
Change-Id: I15261c3737a3284b99308453132f09ee7889c444
Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
Add code to extract the EGL context on QNX for use as the share context
in the Chromium GPU process/thread. Very similar to the other
platforms.
Change-Id: I54fba69283e984a392c11922da2483ce921ea594
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
Change-Id: Iac3ea8525bb70f6f6bc442f486b72dad16e3f545
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>
|
| |
|
|
|
|
|
|
|
| |
Move parts of the initialization from the WebEngineContext
ctor to ContentMainDelegateQt and BrowserMainPartsQt members
so that they are executed in their respective stages of startup.
Change-Id: Iefa288c6bf775ac530f183c0dcfebb6a3230d68d
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.
|
