From kevinushey at gmail.com  Wed Aug  8 04:54:59 2018
From: kevinushey at gmail.com (Kevin Ushey)
Date: Tue, 7 Aug 2018 19:54:59 -0700
Subject: [Qtwebengine] QtWebEngine + ANGLE
Message-ID: <CAJXgQP2ZJJX25ewCDXH=N013WXnXb+Jov-ranP=fEbc+msQNqA@mail.gmail.com>

Hi all,

If I'm understanding correctly, QtWebEngine doesn't support ANGLE, as per
e.g.


http://lists.qt-project.org/pipermail/qtwebengine/2017-August/000461.html
    https://wiki.qt.io/QtWebEngine/Rendering#Rendering_without_the_GPU

For background: we have a number of users on Windows with Intel integrated
graphics cards, and when these users attempt to use the default desktop
OpenGL backend, they often see crashes (e.g. when attempting to load the
associated DLL ig9icd64.dll) or in other cases weird rendering artifacts
(for example, where the page contents are rendered offset from the 'true'
location on the screen). In most cases, upgrading the graphics card drivers
resolves the issue, but many users are unable or unwilling to do this.
Switching to the software renderer is also a viable workaround for these
users, but application performance then suffers. This is especially true
for laptops with high DPI displays.

The Chromium team in a 2015 bug report (
https://bugs.chromium.org/p/chromium/issues/detail?id=561542) suggests that
'--use-gl=desktop' is unmaintained, stating:

    I'd suggest --use-angle=gl instead. That code path's going to be
supported in the future but --use-gl=desktop on Windows is effectively
unmaintained.

and IIUC Chrome by default uses ANGLE by default for rendering (hence
making this the more tested rendering pipeline).

Are there any plans to bring support for ANGLE to QtWebEngine? Am I correct
that switching to ANGLE could be a panacea for this family of rendering
issues? Or is there some other way that I could further configure the
default desktop OpenGL renderer in Qt / QtWebEngine / Chromium that might
help alleviate these sorts of issues while still using hardware accelerated
rendering?

Thanks,
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20180807/e97d8ba4/attachment.html>

From Michael.Bruning at qt.io  Wed Aug  8 10:11:06 2018
From: Michael.Bruning at qt.io (Michael Bruning)
Date: Wed, 8 Aug 2018 08:11:06 +0000
Subject: [Qtwebengine] QtWebEngine + ANGLE
In-Reply-To: <CAJXgQP2ZJJX25ewCDXH=N013WXnXb+Jov-ranP=fEbc+msQNqA@mail.gmail.com>
References: <CAJXgQP2ZJJX25ewCDXH=N013WXnXb+Jov-ranP=fEbc+msQNqA@mail.gmail.com>
Message-ID: <7D7C5792-BCA9-4444-B391-7A207F7CD0B5@qt.io>

Hi Kevin,


> On 8. Aug 2018, at 04:54, Kevin Ushey <kevinushey at gmail.com> wrote:
> 
> Hi all,
> 
> If I'm understanding correctly, QtWebEngine doesn't support ANGLE, as per e.g.
> 
>     http://lists.qt-project.org/pipermail/qtwebengine/2017-August/000461.html
>     https://wiki.qt.io/QtWebEngine/Rendering#Rendering_without_the_GPU
> 

You can use ANGLE with Qt WebEngine on Windows, it just comes with some limitations:
   - we have to turn hardware acceleration off for the Chromium part
   - WebGL does not work

This is due to the fact that when running WebEngine, we usually have two threads accessing the GPU, one being the Qt SceneGraph thread and the other being Chromium’s GPU thread. ANGLE does not handle multithreaded access well (e.g. it may crash or render some weird artefacts) and for that reason, we switch the Chromium part to not use the GPU. The Qt SceneGraph will still use HW acceleration, but Chromium’s content will be rendered in SW prior to being uploaded to the GPU by the SceneGraph.


> For background: we have a number of users on Windows with Intel integrated graphics cards, and when these users attempt to use the default desktop OpenGL backend, they often see crashes (e.g. when attempting to load the associated DLL ig9icd64.dll) or in other cases weird rendering artifacts (for example, where the page contents are rendered offset from the 'true' location on the screen). In most cases, upgrading the graphics card drivers resolves the issue, but many users are unable or unwilling to do this. Switching to the software renderer is also a viable workaround for these users, but application performance then suffers. This is especially true for laptops with high DPI displays.
ANGLE can be used to work around a lot of this driver trouble. If you can live with the limitations mentioned above, switching to ANGLE on Windows may be the way to go for you.

> The Chromium team in a 2015 bug report (https://bugs.chromium.org/p/chromium/issues/detail?id=561542) suggests that '--use-gl=desktop' is unmaintained, stating:
> 
>     I'd suggest --use-angle=gl instead. That code path's going to be supported in the future but --use-gl=desktop on Windows is effectively unmaintained.
> 
> and IIUC Chrome by default uses ANGLE by default for rendering (hence making this the more tested rendering pipeline).
> 
> Are there any plans to bring support for ANGLE to QtWebEngine? Am I correct that switching to ANGLE could be a panacea for this family of rendering issues? Or is there some other way that I could further configure the default desktop OpenGL renderer in Qt / QtWebEngine / Chromium that might help alleviate these sorts of issues while still using hardware accelerated rendering?
> 
> Thanks,
> Kevin


Best regards,
Michael

--
Michael Brüning
Senior Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
http://qt.io

Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--



From jmerel at druide.com  Wed Aug  8 15:21:14 2018
From: jmerel at druide.com (=?UTF-8?Q?Jonathan_M=c3=a9rel?=)
Date: Wed, 8 Aug 2018 09:21:14 -0400
Subject: [Qtwebengine] QtWebEngine + ANGLE
In-Reply-To: <7D7C5792-BCA9-4444-B391-7A207F7CD0B5@qt.io>
References: <CAJXgQP2ZJJX25ewCDXH=N013WXnXb+Jov-ranP=fEbc+msQNqA@mail.gmail.com>
	<7D7C5792-BCA9-4444-B391-7A207F7CD0B5@qt.io>
Message-ID: <69c08262-29e5-c6bc-c2c1-064e4f465162@druide.com>

Hello,

We have tried different settings, to ensure maximum compatibility with old PCs, and we found that "QMLSCENE_DEVICE=softwarecontext" is a good option.

  * QT_OPENGL= desktop (ES2) ==> crash on some PCs, Doesen't support RemoteFX.
  * QT_OPENGL= angle + QT_ANGLE_PLATFORM = d3d11 ==> "Failed to create OpenGL context" in VMs.
  * QT_OPENGL= angle + QT_ANGLE_PLATFORM = warp ==> flicker, resize bugs + black screen with RDP.
  * QT_OPENGL= software ==> black screen with RDP.
  * QMLSCENE_DEVICE=softwarecontext ==> no problems yet, but slower than the other options.

We also tried QT_OPENGL= desktop (MESA) but I don't recall the result.


Jonathan


On 2018-08-08 4:11 AM, Michael Bruning wrote:
> Hi Kevin,
>
>
>> On 8. Aug 2018, at 04:54, Kevin Ushey <kevinushey at gmail.com> wrote:
>>
>> Hi all,
>>
>> If I'm understanding correctly, QtWebEngine doesn't support ANGLE, as per e.g.
>>
>>      http://lists.qt-project.org/pipermail/qtwebengine/2017-August/000461.html
>>      https://wiki.qt.io/QtWebEngine/Rendering#Rendering_without_the_GPU
>>
> You can use ANGLE with Qt WebEngine on Windows, it just comes with some limitations:
>     - we have to turn hardware acceleration off for the Chromium part
>     - WebGL does not work
>
> This is due to the fact that when running WebEngine, we usually have two threads accessing the GPU, one being the Qt SceneGraph thread and the other being Chromium’s GPU thread. ANGLE does not handle multithreaded access well (e.g. it may crash or render some weird artefacts) and for that reason, we switch the Chromium part to not use the GPU. The Qt SceneGraph will still use HW acceleration, but Chromium’s content will be rendered in SW prior to being uploaded to the GPU by the SceneGraph.
>
>
>> For background: we have a number of users on Windows with Intel integrated graphics cards, and when these users attempt to use the default desktop OpenGL backend, they often see crashes (e.g. when attempting to load the associated DLL ig9icd64.dll) or in other cases weird rendering artifacts (for example, where the page contents are rendered offset from the 'true' location on the screen). In most cases, upgrading the graphics card drivers resolves the issue, but many users are unable or unwilling to do this. Switching to the software renderer is also a viable workaround for these users, but application performance then suffers. This is especially true for laptops with high DPI displays.
> ANGLE can be used to work around a lot of this driver trouble. If you can live with the limitations mentioned above, switching to ANGLE on Windows may be the way to go for you.
>
>> The Chromium team in a 2015 bug report (https://bugs.chromium.org/p/chromium/issues/detail?id=561542) suggests that '--use-gl=desktop' is unmaintained, stating:
>>
>>      I'd suggest --use-angle=gl instead. That code path's going to be supported in the future but --use-gl=desktop on Windows is effectively unmaintained.
>>
>> and IIUC Chrome by default uses ANGLE by default for rendering (hence making this the more tested rendering pipeline).
>>
>> Are there any plans to bring support for ANGLE to QtWebEngine? Am I correct that switching to ANGLE could be a panacea for this family of rendering issues? Or is there some other way that I could further configure the default desktop OpenGL renderer in Qt / QtWebEngine / Chromium that might help alleviate these sorts of issues while still using hardware accelerated rendering?
>>
>> Thanks,
>> Kevin
>
> Best regards,
> Michael
>
> --
> Michael Brüning
> Senior Software Engineer
>
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
> http://qt.io
>
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> --
>
>
> _______________________________________________
> QtWebEngine mailing list
> QtWebEngine at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qtwebengine

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20180808/b9644aa5/attachment.html>

From kevinushey at gmail.com  Wed Aug  8 18:16:17 2018
From: kevinushey at gmail.com (Kevin Ushey)
Date: Wed, 8 Aug 2018 09:16:17 -0700
Subject: [Qtwebengine] QtWebEngine + ANGLE
In-Reply-To: <7D7C5792-BCA9-4444-B391-7A207F7CD0B5@qt.io>
References: <CAJXgQP2ZJJX25ewCDXH=N013WXnXb+Jov-ranP=fEbc+msQNqA@mail.gmail.com>
	<7D7C5792-BCA9-4444-B391-7A207F7CD0B5@qt.io>
Message-ID: <CAJXgQP2+pZgQgquah6dqfUmZgXQ-53+_LM3Vnxd=s8_w-p=Dyg@mail.gmail.com>

On Wed, Aug 8, 2018 at 1:11 AM Michael Bruning <Michael.Bruning at qt.io>
wrote:

> Hi Kevin,
>
>
> > On 8. Aug 2018, at 04:54, Kevin Ushey <kevinushey at gmail.com> wrote:
> >
> > Hi all,
> >
> > If I'm understanding correctly, QtWebEngine doesn't support ANGLE, as
> per e.g.
> >
> >
> http://lists.qt-project.org/pipermail/qtwebengine/2017-August/000461.html
> >     https://wiki.qt.io/QtWebEngine/Rendering#Rendering_without_the_GPU
> >
>
> You can use ANGLE with Qt WebEngine on Windows, it just comes with some
> limitations:
>    - we have to turn hardware acceleration off for the Chromium part
>    - WebGL does not work
>
> This is due to the fact that when running WebEngine, we usually have two
> threads accessing the GPU, one being the Qt SceneGraph thread and the other
> being Chromium’s GPU thread. ANGLE does not handle multithreaded access
> well (e.g. it may crash or render some weird artefacts) and for that
> reason, we switch the Chromium part to not use the GPU. The Qt SceneGraph
> will still use HW acceleration, but Chromium’s content will be rendered in
> SW prior to being uploaded to the GPU by the SceneGraph.
>

In our case, our application is effectively a single-page web application
(ie the whole application surface, minus the menu bar, is rendered by
Chromium) so slowness in Chromium rendering implies our application will be
slow. For that reason, I think we need hardware acceleration in Chromium if
at all possible.

Is there any hope that this could be mediated -- for example, by allowing
one to opt-in to using hardware acceleration with ANGLE in Chromium, but
then request that the Qt SceneGraph be rendered in software? (Or is this
something that we would not expect to work?)

> For background: we have a number of users on Windows with Intel
> integrated graphics cards, and when these users attempt to use the default
> desktop OpenGL backend, they often see crashes (e.g. when attempting to
> load the associated DLL ig9icd64.dll) or in other cases weird rendering
> artifacts (for example, where the page contents are rendered offset from
> the 'true' location on the screen). In most cases, upgrading the graphics
> card drivers resolves the issue, but many users are unable or unwilling to
> do this. Switching to the software renderer is also a viable workaround for
> these users, but application performance then suffers. This is especially
> true for laptops with high DPI displays.
> ANGLE can be used to work around a lot of this driver trouble. If you can
> live with the limitations mentioned above, switching to ANGLE on Windows
> may be the way to go for you.
>
> > The Chromium team in a 2015 bug report (
> https://bugs.chromium.org/p/chromium/issues/detail?id=561542) suggests
> that '--use-gl=desktop' is unmaintained, stating:
> >
> >     I'd suggest --use-angle=gl instead. That code path's going to be
> supported in the future but --use-gl=desktop on Windows is effectively
> unmaintained.
> >
> > and IIUC Chrome by default uses ANGLE by default for rendering (hence
> making this the more tested rendering pipeline).
> >
> > Are there any plans to bring support for ANGLE to QtWebEngine? Am I
> correct that switching to ANGLE could be a panacea for this family of
> rendering issues? Or is there some other way that I could further configure
> the default desktop OpenGL renderer in Qt / QtWebEngine / Chromium that
> might help alleviate these sorts of issues while still using hardware
> accelerated rendering?
> >
> > Thanks,
> > Kevin
>
>
> Best regards,
> Michael
>
> --
> Michael Brüning
> Senior Software Engineer
>
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
> http://qt.io
>
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> --
>
>
> _______________________________________________
> QtWebEngine mailing list
> QtWebEngine at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qtwebengine
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20180808/bf7d2a8a/attachment.html>

From kevinushey at gmail.com  Wed Aug  8 19:07:56 2018
From: kevinushey at gmail.com (Kevin Ushey)
Date: Wed, 8 Aug 2018 10:07:56 -0700
Subject: [Qtwebengine] QtWebEngine + ANGLE
In-Reply-To: <69c08262-29e5-c6bc-c2c1-064e4f465162@druide.com>
References: <CAJXgQP2ZJJX25ewCDXH=N013WXnXb+Jov-ranP=fEbc+msQNqA@mail.gmail.com>
	<7D7C5792-BCA9-4444-B391-7A207F7CD0B5@qt.io>
	<69c08262-29e5-c6bc-c2c1-064e4f465162@druide.com>
Message-ID: <CAJXgQP3HX7Fun9o0jH-t8fAPn3HekEhts+z3SZK-YVhp9ffv8g@mail.gmail.com>

Thanks; I hadn't yet thought about setting QMLSCENE_DEVICE here. Currently,
when requesting software rendering we're using a plain old:

    QCoreApplication::setAttribute(Qt::AA_UseSoftwareOpenGL);

which I imagine implies using a software context for the scene renderer as
well, but we'll try testing this out as well.

On Wed, Aug 8, 2018 at 6:21 AM Jonathan Mérel <jmerel at druide.com> wrote:

> Hello,
>
> We have tried different settings, to ensure maximum compatibility with old
> PCs, and we found that "QMLSCENE_DEVICE=softwarecontext" is a good option.
>
>    - QT_OPENGL= desktop (ES2) ==> crash on some PCs, Doesen't support
>    RemoteFX.
>    - QT_OPENGL= angle + QT_ANGLE_PLATFORM = d3d11 ==> "Failed to create
>    OpenGL context" in VMs.
>    - QT_OPENGL= angle + QT_ANGLE_PLATFORM = warp ==> flicker, resize bugs
>    + black screen with RDP.
>    - QT_OPENGL= software ==> black screen with RDP.
>    - QMLSCENE_DEVICE=softwarecontext ==> no problems yet, but slower than
>    the other options.
>
> We also tried QT_OPENGL= desktop (MESA) but I don't recall the result.
>
>
> Jonathan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20180808/93d5d3ef/attachment.html>

From carlon.luca at gmail.com  Sat Aug 11 14:04:44 2018
From: carlon.luca at gmail.com (Luca Carlon)
Date: Sat, 11 Aug 2018 14:04:44 +0200
Subject: [Qtwebengine] SQLite error after building QtWebEngine
Message-ID: <CAMC=D=uhNZimSnDXCkAW1L1Wrc34kuArcMXOzReYvfThA1vCqQ@mail.gmail.com>

Hello everyone,
I built my own version of QtWebEngine to fix an issue I was experiencing,
but my new version seems to be affected by this:
https://bugreports.qt.io/browse/QTBUG-67973. I see it is maked as closed,
so I tried to solution reported: I rebuilt everything with msvc 15.7.x, but
still the same error occurs.

What I did was cloning the QtWebEngine repo, checking out version 5.11.1,
running qmake -r from a build directory and running jom. I'm using qmake
and Qt downloaded with the regular Qt installer. After nmake install the
older webengine libs were replaced with the newer ones.
I therefore tried to run quicknanobrowser and everything was ok at first.
Then I ran it again, and this error appeared:

[6268:2328:0811/130921.593:ERROR:ssl_client_socket_impl.cc(1147)] handshake
failed; returned -1, SSL error code 1, net_error -101
[6268:9236:0811/130923.473:ERROR:connection.cc(1945)] DomainBoundCerts
sqlite error 1555, errno 0: UNIQUE constraint failed: channel_id.host, sql:
INSERT INTO channel_id (host, private_key, public_key, creation_time)
VALUES (?,?,"",?)
[6268:9236:0811/130923.474:ERROR:connection.cc(1945)] DomainBoundCerts
sqlite error 1555, errno 0: UNIQUE constraint failed: channel_id.host, sql:
INSERT INTO channel_id (host, private_key, public_key, creation_time)
VALUES (?,?,"",?)
[6268:1360:0811/130928.559:ERROR:connection.cc(1945)] DomainBoundCerts
sqlite error 1555, errno 0: UNIQUE constraint failed: channel_id.host, sql:
INSERT INTO channel_id (host, private_key, public_key, creation_time)
VALUES (?,?,"",?)
[6268:2328:0811/131005.766:ERROR:ssl_client_socket_impl.cc(1147)] handshake
failed; returned -1, SSL error code 1, net_error -101
[6268:2328:0811/131017.577:ERROR:ssl_client_socket_impl.cc(1147)] handshake
failed; returned -1, SSL error code 1, net_error -101

Tried to remove the app cache, but nothing changed. I'm stuck here. Any
idea what could be the cause of this? Maybe some global QtWebEngine cache
to clean?
Regards.

Luca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20180811/344fd1a0/attachment.html>

From list.adam at twardoch.com  Sat Aug 25 01:18:10 2018
From: list.adam at twardoch.com (Adam Twardoch (Lists))
Date: Sat, 25 Aug 2018 01:18:10 +0200
Subject: [Qtwebengine] PDF/HTML -> SVG via QWebEngine + PDFium + Skia +
 SkCanvas + SkSVGCanvas?
Message-ID: <CAG32G7OWthtCpyuMm3uKi_Zh+xVEsxNxqOfZBfRN2e9WoTPvUw@mail.gmail.com>

Hello all,

My understanding is that the QWebEngine project includes both the PDFium
PDF renderer and the Skia drawing library.

- https://pdfium.googlesource.com/pdfium/
- https://skia.org
- https://github.com/google/skia

PDFium has a Skia backend, which means that it can render a PDF onto an
SkCanvas canvas.

- https://pdfium.googlesource.com/pdfium/+/master/core/fxge/skia/
- https://skia.org/user/api/skcanvas_overview
-
https://github.com/amplab/ray-core/blob/master/src/examples/ui/pdf_viewer/pdf_viewer.cc

Skia has an SkSVGCanvas backend, which can render an SkCanvas into SVG.

- https://github.com/google/skia/tree/master/include/svg
- https://github.com/google/skia/tree/master/src/svg
- https://github.com/google/skia/blob/master/include/svg/SkSVGCanvas.h
- https://github.com/google/skia/blob/master/src/svg/SkSVGCanvas.cpp

Would it be possible to:

1. Render any QWebEngine view or page into SkCanvas and then into SVG?

If Qt were to do it, it could be exposed in an API similar to
QWebEnginePage::printToPdf. This would allow developers to render any web
content not just as a bitmap but also as an SVG, and then use one of the
many SVG processing methods to do something further with it.

2. "Convert" any PDF into SVG using that method?

Sinve QWebEngine can render PDF content into its view, it might be possible
to use the above method to end up with a PDF->SVG conversion, all using
on-board means with permissive licensing.

Regards,
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20180825/9de01add/attachment.html>