[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Distros and QtWebEngine
From: Kevin Kofler <kevin.kofler () chello ! at>
Date: 2015-04-21 16:13:03
Message-ID: mh5suk$1se$1 () ger ! gmane ! org
[Download RAW message or body]
Lisandro Damián Nicanor Pérez Meyer wrote:
> Actually when it comes to the web engine it's not true. When I suggested
> to use an external ffmpeg and libv8 (javascript engine) the answer was
> directly no, simply because they are too entangled to be possible. And
> ffmpeg tends to be quite a source of CVEs...
Not to mention that we want our web browsers to not use FFmpeg at all (at
least not directly), but GStreamer 1. Sadly, due to how deeply FFmpeg is
entangled into Chromium, this does not look realistic for QtWebEngine. Using
GStreamer would mean that we could ship it only with unencumbered codecs
while still allowing our users to easily add patent-encumbered codecs, the
same codecs would work for all applications, and there would also be an
automated plugin installation mechanism. Chromium's hardcoded use of a
forked FFmpeg breaks all that.
We also want our web browsers to support a JavaScript engine that has a non-
JIT fallback, because the JIT does not work on our secondary architectures.
(For Debian, those are even PRIMARY architectures!) This is even less
realistic in Chromium, because V8 is hardcoded everywhere, and there is no
interest whatsoever in V8 upstream in supporting an interpreter fallback.
This issue means anything that requires QtWebEngine in KDE will NOT be
available on all those platforms, even if we were to package QtWebEngine.
(It would also increase our maintenance workload if we were to package
QtWebEngine, by requiring ExcludeArch or ExclusiveArch lists all over the
place.)
Kevin Kofler
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic