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

Juergen Ryannel juergen.bocklage-ryannel at pelagicore.com
Tue Aug 9 21:43:21 CEST 2016

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> 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/ <https://codereview.qt-project.org/#/c/167483/>
> > 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/20160809/c6cef06d/attachment.html>

More information about the Automotive mailing list