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

Martin Kampas martin.kampas at jolla.com
Tue Aug 9 17:29:07 CEST 2016


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/

> 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/2daefd26/attachment.html>


More information about the Automotive mailing list