[Development] Assistant WebKit/WebEngine support
Nikolai Kosjar
Nikolai.Kosjar at qt.io
Thu Jun 27 09:07:59 CEST 2019
On 6/27/19 3:47 AM, Lars Knoll wrote:
>> On 26 Jun 2019, at 23:16, Eike Ziller <Eike.Ziller at qt.io> wrote:
>>
>>
>>
>>> On 26. Jun 2019, at 13:47, Simon Hausmann <Simon.Hausmann at 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-bounces at qt-project.org> on behalf of Michal Klocek <michal.klocek at qt.io>
>>> Sent: Wednesday, June 26, 2019 13:31
>>> To: development at 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 at qt-project.org
>>>> https://lists.qt-project.org/listinfo/development
>>>>
>>> _______________________________________________
>>> Development mailing list
>>> Development at qt-project.org
>>> https://lists.qt-project.org/listinfo/development
>>> _______________________________________________
>>> Development mailing list
>>> Development at 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.ziller at 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 at qt-project.org
>> https://lists.qt-project.org/listinfo/development
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
More information about the Development
mailing list