[Automotive] QmlLive: Is LiveNodeEngine::RecreateView mode really needed?

[Juergen Ryannel]

Hi Martin,

We use the embedded in-bench view currently to create controls or to work on isolated panels. Running the whole project crashes frequently, often inside native plugins. The project(s) we are working on use always custom qmlscenes which do not use a QQuickView just a QQmlEngine. 

If going forward and being able to extract a (reusable) live reloading library out of QmlLive this library should only assume the user has some kind of QQmlEngine, more we should not assume from the user. Hence my desire to make the core of QmlLive only depending on a QQmlEngine.

And because of the frequent crashing of the native plugins my desire to reload out-of-process. Hope this information helps you.

Note: The WindowWidget should normally capture the Window and “embed” it back into the QmlLiveBench. This seems to be broken currently.


/ jryannel



> On 10.08.2016, at 13:50, Martin Kampas <martin.kampas at jolla.com> wrote:
> 
> Hi Jürgen,
> 
> > We currently never use a QQuickView and normally require the root item to be a Window or if not to create a Window and reparent the item.
> 
> Does this mean you do not actively use the embedded in-bench view nowadays? IIUC loading a QML component with Window as the root item always creates a separate window, not embedded in the bench.
> 
> BR,
> Martin
> 
> From: Juergen Ryannel [juergen.bocklage-ryannel at pelagicore.com]
> Sent: Tuesday, August 09, 2016 9:43 PM
> To: Martin Kampas
> Cc: automotive at qt-project.org; Dominik Holland
> Subject: Re: QmlLive: Is LiveNodeEngine::RecreateView mode really needed?
> 
> Hi Martin,
> 
> Thanks for the proposal, sounds exactly like I would like to go forward with. I would even like to get ride of the QQuickView altogether (so on (3) not even optional. We currently never use a QQuickView and normally require the root item to be a Window or if not to create a Window and reparent the item.
> 
> I’m currently on holiday, but I’m happy to review your patches. Thanks for looking into this.
> 
> / jryannel
> 
> 
>> On 09.08.2016, at 17:29, Martin Kampas <martin.kampas at jolla.com <x-msg://7/redir.aspx?REF=6-yQkrNfDkaxtwPL2vE6wvyM57BRBC_OVdwhvffwtT05bbSpE8HTCAFtYWlsdG86bWFydGluLmthbXBhc0Bqb2xsYS5jb20.>> wrote:
>> 
>> Hi Jürgen,
>> 
>> > We had some issues where content (e.g. QML, images, …) where cached and survived a clearComponentCache call. [...]
>> 
>> You are right, images need additional handling in addition to clearComponentCache - there is QQuickWindow::releaseResources() which fixes it. Verified with a QML Image element https://codereview.qt-project.org/#/c/167483/ <x-msg://7/redir.aspx?REF=uFO-hgrs5YBl9zd6UF_xKZ5jarfnUwURuDO2WsHSvMo5bbSpE8HTCAFodHRwczovL2NvZGVyZXZpZXcucXQtcHJvamVjdC5vcmcvIy9jLzE2NzQ4My8.>
>> 
>> > Ideally we would not use a QQuickView at all and just depend on a QQmlEngine.
>> 
>> Also my opinion - proposed in my reply to Dominik Holland.
>> 
>> > Additionally we would like to create the out-of-process option, where we control a remote process. This makes it easier to survive crashes from C++ plugins.
>> 
>> I understand this feature to be rather orthogonal to the mechanism of reloading. Maybe as a last sort mechanism when things go bad. I would see it better to be implemented somewhere above LiveNodeEngine.
>> 
>> Here is my proposal I wrote in my reply to Dominik Holland extended w.r.t your comments:
>> 
>> I propose to
>> 
>> 1) remove the RecreateView mode and only rely on QQmlEngine::clear/trimComponentCache() and QQuickWindow::releaseResources()
>> 2) require to set QQmlEngine and make setting QQuickView optional (useless when the QML component instantiates QQuickWindow)
>> 3) only after that fix memory leaks in LiveNodeEngine :)
>> 4) remove the UpdateMode enum as no mode selection is needed anymore. Single implementation works in all cases; out-of-process control would be implemented as a feature orthogonal to the mechanism of reloading, not as another mutualy exclusive option.
>> 
>> If you agree I will contribute patches for this.
>> 
>> BR,
>> Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/automotive/attachments/20160810/d10738d2/attachment-0001.html>