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

Reply via email to