On 6/27/19 3:47 AM, Lars Knoll wrote: >> On 26 Jun 2019, at 23:16, Eike Ziller <eike.zil...@qt.io> wrote: >> >> >> >>> On 26. Jun 2019, at 13:47, Simon Hausmann <simon.hausm...@qt.io> wrote: >>> >>> Hi, >>> >>> From my earlier email: >>> >>> " 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.” >> >> From Activity Monitor on macOS, it looks like here the memory consumption >> increase compared to QTextBrowser is about >> 40 MB for the Qt Creator process + 20-40 MB for the QtWebEngineProcess >> >> per simultaneously opened page. >> >> So, that is something like a 140 MB RAM increase if you don’t explicitly >> open documentation in additional “tabs”, >> since by default we have one viewer for context help beside the editor, and >> the viewer in Help mode. >> If you additionally show some documentation in an external window (happens >> when opening examples), that’s about 210 MB RAM usage increase then. > > Yes, Webengine uses some memory. But is that really a problem on developer > machines? > > People propose adding functionality to QTextBrowser instead. I do not thing > that’s a viable solution (we’ve tried that in the past and our technical > writers hit the next issue some weeks/months later). The problem is not that > one could not add support for one or two new features to QTextBrowser, it is > that we do not know what features we will need in our docs in the future.
I would expect a rather limited feature set for displaying documentation. So I'm wondering whether/how the requirements changed for that in e.g. the last years? > And that we (as Kavindra pointed out) are wasting a lot of our technical > writers time trying to ensure the content is rendered in a somewhat usable > way in Creator. This is frustrating to those people who are trying to create > as good as possible documentation for Qt and leads to us having worse quality > documentation than we could. > > Using Qt Webengine to render the docs is a rather straightforward and easy > solution to this problem. The additional memory usage is a rather small price > to pay for better usability of our docs, giving our technical writers more > options and simplifying their lives. > > Qt used to make a point on having superior documentation to most other > frameworks, and it was (and still is) one of the reasons for its success. > Whatever we can do to help make the documentation better is something I think > we should do. > > Cheers, > Lars > >> >> Br, Eike >> >>> That number came from the task manager in Windows. >>> >>> Simon >>> From: Development <development-boun...@qt-project.org> on behalf of Michal >>> Klocek <michal.klo...@qt.io> >>> Sent: Wednesday, June 26, 2019 13:31 >>> To: development@qt-project.org >>> Subject: Re: [Development] Assistant WebKit/WebEngine support >>> >>> Could you explain how did you measure web engine memory consumption to >>> get 14-20MB of ram ? >>> >>> On 6/26/19 1:12 PM, Simon Hausmann wrote: >>>> >>>> Am 25.06.19 um 23:53 schrieb Konrad Rosenbaum: >>>>> Option 4: convert to WebEngine >>>>> Pros: looks great; currently supported browser engine, only little >>>>> porting work >>>>> Cons: horrible memory footprint; acute terminal featuritis; adds lots of >>>>> dependencies (disqualifies it for most/many people redistributing it); >>>>> does not work on all platforms supported by Qt (makes assistant less >>>>> useful or even useless to those users); embedding in IDEs becomes much >>>>> more difficult (dependencies and #ifdef's for unsupported platforms) >>>> >>>> >>>> I'd really like to eliminate this myth of a "horrible memory footprint". >>>> I sent an email earlier in this thread regarding this and presented >>>> numbers that suggest otherwise for documentation content. >>>> >>>> >>>> >>>> Simon >>>> >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development@qt-project.org >>>> https://lists.qt-project.org/listinfo/development >>>> >>> _______________________________________________ >>> Development mailing list >>> Development@qt-project.org >>> https://lists.qt-project.org/listinfo/development >>> _______________________________________________ >>> Development mailing list >>> Development@qt-project.org >>> https://lists.qt-project.org/listinfo/development >> >> -- >> Eike Ziller >> Principal Software Engineer >> >> The Qt Company GmbH >> Rudower Chaussee 13 >> D-12489 Berlin >> eike.zil...@qt.io >> http://qt.io >> Geschäftsführer: Mika Pälsi, >> Juha Varelius, Mika Harjuaho >> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, >> HRB 144331 B >> >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development > > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development