[Development] Assistant WebKit/WebEngine support

Konstantin Tokarev annulen at yandex.ru
Mon Jun 24 15:37:16 CEST 2019



24.06.2019, 15:46, "Simon Hausmann" <simon.hausmann at qt.io>:
> Am 24.06.19 um 12:31 schrieb Eike Ziller:
>>>  * What exactly is so big about WebEngine? What is this size that many are hinting at but won't provide the number?
>>  My numbers on macOS:
>>
>>  WebEngineCore.framework = 145 MB
>>  Current Qt Creator application = 430 MB (and about 60 MB of this we currently try to get rid off again because it’s actually duplicate binary code)
>
> I have two more numbers to add: Compressed (7z) the download size would
> be around ~44 MB. I measured on Windows with a Qt Creator built with
> WebEngine support and surfed a little through the docs. The memory
> consumption of the web engine process weighed in between 14-20 MB of RAM.
>
> So it looks like this AFAICS:
>
>      * We would be adding 145 MB of additional disk usage
>
>      * We would add ~44 MB to the download size of Qt Creator
>
>      * We would eat ~14-20 MB of additional RAM (not quite fair though,
> as we'd have to subtract the QTextDocument memory usage for a diff).

For comparison, numbers for QtWebKit are: 84 MB of disk space (of which
26 MB is taken by ICU data), and 20 MB when compressed to 7z archive.
I didn't measure RAM consumption, but I'm sure it won't take more than
you've measured.

This is full build with all features enabled; it's possible to make reduced
build without multimedia support, JavaScript JIT and other features not needed
for help browser.

>
> I don't quite share the opinion that these are "beastly" numbers for
> desktop machines running C++ development environments. I think that they
> are worth it. In exchange we can show external content like cppreference
> or cmake docs without having to worry about their rendering, we can get
> rid of our separate style sheets and workarounds and we can render the
> Qt documentation the same way as on the website. We can eliminate an
> entire class of problems, and we can still prevent such content from
> accessing remote websites.
>
> We've had this situation for a long time now and I think that we should
> finally move forward and give our users better quality at the expense of
> their disk space, memory consumption and download size.
>
> Simon
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Regards,
Konstantin




More information about the Development mailing list