24.06.2019, 15:46, "Simon Hausmann" <simon.hausm...@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@qt-project.org > https://lists.qt-project.org/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development