Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
Hi, Am Thu Oct 02 2014 08:56:53 GMT+0200 (CEST) schrieb Iosif Hamlatzis: > Reading all these and previous similar changes I was wondering why other > mobile platforms don't have this issue? If I'm not mistaken in no other > mobile platform the developer has to take into account if his/her > application goes into the background. Well, that's a considerably low price you have to pay for multitasking. The other platforms don't support multitasking for apps, only for services, and thus developers don't need to care because the app is acting dead / frozen / killed while not visible. SailfishOS is different in this regard as it employs desktop-class multitasking and the apps are truly running side by side instead of simulating the impression more or less well. Therefore, apps shouldn't eat all RAM alone and should free unneeded resources where applicable. 1 GB of RAM is not that much. Martin -- ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
On 02 Oct 2014, at 09:29, wrote: > Hello, > > Selon Iosif Hamlatzis : >> Reading all these and previous similar changes I was wondering why other >> mobile platforms don't have this issue? > IMHO, there is a misunderstanding here, as far as I've understood, most of > applications don't have to take care of going to background and coming back. > When the application comes back, there is a repaint call() that is done > automatically, and the application redraws itself. The only corner case is > when > the application supposes that the repaint call doesn't start with a clear() > call. For instance when the drawing operation is heavy and redraw is done only > by updating the buffer. In that case only the developer would have to redraw > from scratch when the application comes back from background. You are right and the cornercase is even a bit more narrow. It is if a QML application relies on an OpenGL resource being present after coming back. In this case, because Canvas is set to use a FramebufferObject (which is not the default), the resource is a fresh one after coming back. Any QML ui which uses only Silica or the stock QtQuick components is still unaffected. Releasing doesn't happen for pure EGL/GL or SDL based games. It is only for QML applications which explicitly use OpenGL resources. > It seems to me that holding the copy of the buffer before going to background > is > indeed what the new way to do is trying to avoid, keep memory (a copy of the > full screen is costly) usage low when multitasking. > > My two cents, hoping that I'm not wrong, > > Damien. > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
On 02 Oct 2014, at 08:56, Iosif Hamlatzis wrote: > Reading all these and previous similar changes I was wondering why other > mobile platforms don't have this issue? If I'm not mistaken in no other > mobile platform the developer has to take into account if his/her application > goes into the background. > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org This is true. On most other mobile platforms the application will be deactivated, then suspended, then killed. On Sailfish OS, because it is a true multitasking environment, the application stays fully alive. What we're trying to do is to release as much of the application as possible behind the application's back. The only affected case is when the QML application relies on OpenGL resources being retained between hide and show. cheers, Gunnar www.sletta.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
Hello, Selon Iosif Hamlatzis : > Reading all these and previous similar changes I was wondering why other > mobile platforms don't have this issue? IMHO, there is a misunderstanding here, as far as I've understood, most of applications don't have to take care of going to background and coming back. When the application comes back, there is a repaint call() that is done automatically, and the application redraws itself. The only corner case is when the application supposes that the repaint call doesn't start with a clear() call. For instance when the drawing operation is heavy and redraw is done only by updating the buffer. In that case only the developer would have to redraw from scratch when the application comes back from background. It seems to me that holding the copy of the buffer before going to background is indeed what the new way to do is trying to avoid, keep memory (a copy of the full screen is costly) usage low when multitasking. My two cents, hoping that I'm not wrong, Damien. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
Reading all these and previous similar changes I was wondering why other mobile platforms don't have this issue? If I'm not mistaken in no other mobile platform the developer has to take into account if his/her application goes into the background. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
I see.. So if this pattern is more common then perhaps a different strategy is
in order. Thinking out loud:
One option we could implement is to have a hint on the canvas that it should be
retained. Meaning, when the application is hidden and the scene graph and the
GL context is invalidated, we could do a pixel readback inside the canvas. Then
afterwards, when the canvas comes back, we upload that image into the new FBO
so the application wouldn't notice that the FBO had been released and then
recreated.
It would mean the application kept a system-side copy of the canvas while
hidden, but at least all the other graphics resources would be released.
Perhaps this should even be the default behavior for FBO and the hint is opt-in
for improved memory usage and faster hide/show behavior.
cheers,
Gunnar
www.sletta.org
On 29 Sep 2014, at 23:44, Kimmo Lindholm wrote:
> Yes, I did choose this way by the nature of my paint application.
> Potentially recording all strokes etc. could consume also some amount of
> memory,
> and maybe make the usage-experience tacky.
>
> On charts etc, I also would redraw, and the data "is there".
>
> I have another app where I need to implement that other method too.
>
> -kimmo
>
> On 29 Sep 2014, at 16:43, Mohammed Hassan wrote:
>
>> On Sat, 27 Sep 2014 16:28:42 +
>> Kimmo Lindholm wrote:
>>
>>> Hi,
>>>
>>> Just wanted to give a follow-up on this topic;
>>>
>>> You are affected if you are drawing on Canvas (and don't want to
>>> repaint it completely when returning to application) Symptom is that
>>> canvas gets cleared when going away from application (minimizing it
>>> to cover)
>>>
>>> The simplest way to not allow releasing, add two middle lines in your
>>> main() as suggested in original email;
>>>
>>> view->setSource(SailfishApp::pathTo("qml/ankkuri.qml"));
>>> view->setPersistentOpenGLContext(true);
>>> view->setPersistentSceneGraph(true);
>>> view->show();
>>
>> I'd personally not recommend doing that just because you don't want to
>> repaint. Releasing the resources decreases the memory footprint of the
>> application when minimized and allows the system to stay more
>> responsive.
>>
>> If a lot of apps start to not release the GL context and scene graph GL
>> bits then that will negatively impact the whole system.
>>
>> Just my 0.02
>
> I completely agree :)
>
> Though setting the persistent GL/SG flags is very helpful "to get it running"
> after the change over, I would suggest that applications try to avoid it when
> possible.
>
> For the case of Canvas, the problem arises if the application uses
> Canvas.FramebufferObject AND relies on the contents of the canvas not being
> cleared between calls to Canvas.onPaint. It should be a pretty rare scenario.
> However, for this specific scenario, there is no good alternative, so it is
> the tool of choice.
>
> cheers,
> Gunnar
>
> www.sletta.org
>
>>
>> Cheers,
>> ___
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
>
>
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
Yes, I did choose this way by the nature of my paint application.
Potentially recording all strokes etc. could consume also some amount of memory,
and maybe make the usage-experience tacky.
On charts etc, I also would redraw, and the data "is there".
I have another app where I need to implement that other method too.
-kimmo
On 29 Sep 2014, at 16:43, Mohammed Hassan wrote:
> On Sat, 27 Sep 2014 16:28:42 +
> Kimmo Lindholm wrote:
>
>> Hi,
>>
>> Just wanted to give a follow-up on this topic;
>>
>> You are affected if you are drawing on Canvas (and don't want to
>> repaint it completely when returning to application) Symptom is that
>> canvas gets cleared when going away from application (minimizing it
>> to cover)
>>
>> The simplest way to not allow releasing, add two middle lines in your
>> main() as suggested in original email;
>>
>> view->setSource(SailfishApp::pathTo("qml/ankkuri.qml"));
>> view->setPersistentOpenGLContext(true);
>> view->setPersistentSceneGraph(true);
>> view->show();
>
> I'd personally not recommend doing that just because you don't want to
> repaint. Releasing the resources decreases the memory footprint of the
> application when minimized and allows the system to stay more
> responsive.
>
> If a lot of apps start to not release the GL context and scene graph GL
> bits then that will negatively impact the whole system.
>
> Just my 0.02
I completely agree :)
Though setting the persistent GL/SG flags is very helpful "to get it running"
after the change over, I would suggest that applications try to avoid it when
possible.
For the case of Canvas, the problem arises if the application uses
Canvas.FramebufferObject AND relies on the contents of the canvas not being
cleared between calls to Canvas.onPaint. It should be a pretty rare scenario.
However, for this specific scenario, there is no good alternative, so it is the
tool of choice.
cheers,
Gunnar
www.sletta.org
>
> Cheers,
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
On 29 Sep 2014, at 16:43, Mohammed Hassan wrote:
> On Sat, 27 Sep 2014 16:28:42 +
> Kimmo Lindholm wrote:
>
>> Hi,
>>
>> Just wanted to give a follow-up on this topic;
>>
>> You are affected if you are drawing on Canvas (and don't want to
>> repaint it completely when returning to application) Symptom is that
>> canvas gets cleared when going away from application (minimizing it
>> to cover)
>>
>> The simplest way to not allow releasing, add two middle lines in your
>> main() as suggested in original email;
>>
>> view->setSource(SailfishApp::pathTo("qml/ankkuri.qml"));
>> view->setPersistentOpenGLContext(true);
>> view->setPersistentSceneGraph(true);
>> view->show();
>
> I'd personally not recommend doing that just because you don't want to
> repaint. Releasing the resources decreases the memory footprint of the
> application when minimized and allows the system to stay more
> responsive.
>
> If a lot of apps start to not release the GL context and scene graph GL
> bits then that will negatively impact the whole system.
>
> Just my 0.02
I completely agree :)
Though setting the persistent GL/SG flags is very helpful "to get it running"
after the change over, I would suggest that applications try to avoid it when
possible.
For the case of Canvas, the problem arises if the application uses
Canvas.FramebufferObject AND relies on the contents of the canvas not being
cleared between calls to Canvas.onPaint. It should be a pretty rare scenario.
However, for this specific scenario, there is no good alternative, so it is the
tool of choice.
cheers,
Gunnar
www.sletta.org
>
> Cheers,
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
On Sat, 27 Sep 2014 16:28:42 +
Kimmo Lindholm wrote:
> Hi,
>
> Just wanted to give a follow-up on this topic;
>
> You are affected if you are drawing on Canvas (and don't want to
> repaint it completely when returning to application) Symptom is that
> canvas gets cleared when going away from application (minimizing it
> to cover)
>
> The simplest way to not allow releasing, add two middle lines in your
> main() as suggested in original email;
>
> view->setSource(SailfishApp::pathTo("qml/ankkuri.qml"));
> view->setPersistentOpenGLContext(true);
> view->setPersistentSceneGraph(true);
> view->show();
I'd personally not recommend doing that just because you don't want to
repaint. Releasing the resources decreases the memory footprint of the
application when minimized and allows the system to stay more
responsive.
If a lot of apps start to not release the GL context and scene graph GL
bits then that will negatively impact the whole system.
Just my 0.02
Cheers,
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
Hi,
Just wanted to give a follow-up on this topic;
You are affected if you are drawing on Canvas (and don't want to repaint it
completely when returning to application)
Symptom is that canvas gets cleared when going away from application
(minimizing it to cover)
The simplest way to not allow releasing, add two middle lines in your main() as
suggested in original email;
view->setSource(SailfishApp::pathTo("qml/ankkuri.qml"));
view->setPersistentOpenGLContext(true);
view->setPersistentSceneGraph(true);
view->show();
-kimmo
-Original Message-
From: devel-boun...@lists.sailfishos.org
[mailto:devel-boun...@lists.sailfishos.org] On Behalf Of Gunnar Sletta
Sent: Tuesday, May 06, 2014 12:55 PM
To: devel@lists.sailfishos.org
Subject: [SailfishDevel] Upcoming behavioural change with how graphics
resources are handled.
Hi,
If you are not using OpenGL directly or the Qt Quick scene graph's C++ API,
please ignore this mail.
Qt Quick and the scene graphs supports releasing its graphics resources when
the application is not rendering. This is not a feature we have been taking
advantage of so far, but as you can guess, it can be quite beneficial on a
multitasking system to release unused graphics memory.
Once we move our stack to Qt 5.2, we will change the defaults of
http://qt-project.org/doc/qt-5/qquickwindow.html#setPersistentSceneGraph and
http://qt-project.org/doc/qt-5/qquickwindow.html#setPersistentOpenGLContext
to be "false" meaning that when an application is not on screen, its graphics
memory and OpenGL context will be deleted.
- Applications using Qt Quick, Sailfish Silica Components combined with
non-graphical C++ APIs are not affected.
- Applications using only QML-level API, including ShaderEffect or
CustomParticle, are not affected.
- Applications using QWindow and QOpenGLContext and not Qt Quick are also not
affected.
- Covers are unaffected.
Only applications using Qt Quick, QSG-classes and/or QOpenGLContext and/or raw
OpenGL calls ARE affected. If this applies to you, there are two ways to deal
with graphics stuff being released:
1. Don't allow releasing.
This is a valid scenario in many cases. Shaders have been compiled, resources
loaded, etc and rebuilding this is difficult, take too long to be feasible or
some times not possible at all. If so, add the following two lines to your
main.cpp AFTER you told it to load the QML file and BEFORE you show it.
QQuickWindow::setPersistentSceneGraph(true);
QQuickWindow::setPersistentOpenGL(true);
This will revert to the current behaviour where graphics resources are
retained, even when the application is backgrounded.
2. React and handle it.
Use the QQuickWindow::sceneGraphInvalidated() and
QOpenGLContext::aboutToBeDestroyed() signals to clean up your graphics
resources and let your application handle not being shown on screen.
---
I can't tell you when the change over happens, but we're aiming for some time
later this year :) I'm giving you an early heads up so you can update your
applications now if you are affected. Reacting to
http://qt-project.org/doc/qt-5/qquickwindow.html#sceneGraphInvalidated or
http://qt-project.org/doc/qt-5/qopenglcontext.html#aboutToBeDestroyed is
something something you can already do. Same if you want to avoid the issue all
together and setPersistent(SceneGraph|OpenGL)(true) right away. These APIs have
been there since Qt 5.0.
---
If you have further questions, please feel free to ask.
cheers,
Gunnar (sletta on IRC)
___
SailfishOS.org Devel mailing list
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
You are only affected if you use QtQuick in combination with OpenGL and the QSG classes. Raw OpenGL, SDL, etc is not affected. cheers, Gunnar On 06 May 2014, at 15:32, Iosif Hamlatzis wrote: > What about developers such as myself who doesn't use Qt at all but c/c++ with > OpenGL directly. > > Then these calls aren't available: > > QQuickWindow::setPersistentSceneGraph(true); > QQuickWindow::setPersistentOpenGL(true); > > The same for: > > QQuickWindow::sceneGraphInvalidated() > QOpenGLContext::aboutToBeDestroyed() > > > > ___ > SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
What about developers such as myself who doesn't use Qt at all but c/c++ with OpenGL directly. Then these calls aren't available: QQuickWindow::setPersistentSceneGraph(true); QQuickWindow::setPersistentOpenGL(true); The same for: QQuickWindow::sceneGraphInvalidated() QOpenGLContext::aboutToBeDestroyed() ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
On 06 May 2014, at 12:19, David Greaves wrote: > On 06/05/14 10:55, Gunnar Sletta wrote: > >> to be "false" meaning that when an application is not on screen, its graphics >> memory and OpenGL context will be deleted. > > What does on screen mean? Since > >> affected. - Covers are unaffected. > > my cover shows the GL context - so I'm not sure quite how this will work > :) Being on screen means the app is visible. When it is not visible, it should be prepared to handle the case where its graphics resources go away or request that they don't go away using the setPersistent.. API. When I said Covers are unaffected, I should have said. Covers on applications with explicit cover windows are not affected. Applications which does not implement a cover will get their application main window as a cover window. In this case, the memory will be released when neither the cover nor the application is visible. For instance, when the device goes to the lock screen. This does however bring forth another potential issue with Qt 5.2 (which is unrelated to Sailfish OS, but still might affect some users). In Qt 5.2, each QQuickWindow will have its own OpenGL context and these are not sharing. > >> Only applications using Qt Quick, QSG-classes and/or QOpenGLContext and/or >> raw OpenGL calls ARE affected. If this applies to you, there are two ways to >> deal with graphics stuff being released: >> >> 1. Don't allow releasing. >> >> main.cpp AFTER you told it to load the QML file and BEFORE you show it. >> >> QQuickWindow::setPersistentSceneGraph(true); >> QQuickWindow::setPersistentOpenGL(true); >> >> This will revert to the current behaviour where graphics resources are >> retained, even when the application is backgrounded. > > One concern is that putting these in the wrong place will of course not be a > problem until the switch and then at that point the app will break. > > Hopefully we'll have the public update-RC programme in place by then so app > developers can do QA :) *nod* > >> 2. React and handle it. >> >> Use the QQuickWindow::sceneGraphInvalidated() and >> QOpenGLContext::aboutToBeDestroyed() signals to clean up your graphics >> resources and let your application handle not being shown on screen. > > I assume this is not testable for Harbour apps until 5.2 is actually released? It is not testable for Harbour apps, but you can test the impact using stock Qt on for instance Linux or Mac and setting the parameters to false and then calling hide() on the window, for instance. > >> --- >> >> I can't tell you when the change over happens, but we're aiming for some time >> later this year :) I'm giving you an early heads up so you can update your >> applications now if you are affected. Reacting to >> http://qt-project.org/doc/qt-5/qquickwindow.html#sceneGraphInvalidated or >> http://qt-project.org/doc/qt-5/qopenglcontext.html#aboutToBeDestroyed is >> something something you can already do. Same if you want to avoid the issue >> all together and setPersistent(SceneGraph|OpenGL)(true) right away. These >> APIs have been there since Qt 5.0. > > ah - thanks. I wasn't sure when individual methods appeared :) > > David > ___ > SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
On 06/05/14 10:55, Gunnar Sletta wrote: > to be "false" meaning that when an application is not on screen, its graphics > memory and OpenGL context will be deleted. What does on screen mean? Since > affected. - Covers are unaffected. my cover shows the GL context - so I'm not sure quite how this will work :) > Only applications using Qt Quick, QSG-classes and/or QOpenGLContext and/or > raw OpenGL calls ARE affected. If this applies to you, there are two ways to > deal with graphics stuff being released: > > 1. Don't allow releasing. > > main.cpp AFTER you told it to load the QML file and BEFORE you show it. > > QQuickWindow::setPersistentSceneGraph(true); > QQuickWindow::setPersistentOpenGL(true); > > This will revert to the current behaviour where graphics resources are > retained, even when the application is backgrounded. One concern is that putting these in the wrong place will of course not be a problem until the switch and then at that point the app will break. Hopefully we'll have the public update-RC programme in place by then so app developers can do QA :) > 2. React and handle it. > > Use the QQuickWindow::sceneGraphInvalidated() and > QOpenGLContext::aboutToBeDestroyed() signals to clean up your graphics > resources and let your application handle not being shown on screen. I assume this is not testable for Harbour apps until 5.2 is actually released? > --- > > I can't tell you when the change over happens, but we're aiming for some time > later this year :) I'm giving you an early heads up so you can update your > applications now if you are affected. Reacting to > http://qt-project.org/doc/qt-5/qquickwindow.html#sceneGraphInvalidated or > http://qt-project.org/doc/qt-5/qopenglcontext.html#aboutToBeDestroyed is > something something you can already do. Same if you want to avoid the issue > all together and setPersistent(SceneGraph|OpenGL)(true) right away. These > APIs have been there since Qt 5.0. ah - thanks. I wasn't sure when individual methods appeared :) David ___ SailfishOS.org Devel mailing list
[SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
Hi, If you are not using OpenGL directly or the Qt Quick scene graph's C++ API, please ignore this mail. Qt Quick and the scene graphs supports releasing its graphics resources when the application is not rendering. This is not a feature we have been taking advantage of so far, but as you can guess, it can be quite beneficial on a multitasking system to release unused graphics memory. Once we move our stack to Qt 5.2, we will change the defaults of http://qt-project.org/doc/qt-5/qquickwindow.html#setPersistentSceneGraph and http://qt-project.org/doc/qt-5/qquickwindow.html#setPersistentOpenGLContext to be "false" meaning that when an application is not on screen, its graphics memory and OpenGL context will be deleted. - Applications using Qt Quick, Sailfish Silica Components combined with non-graphical C++ APIs are not affected. - Applications using only QML-level API, including ShaderEffect or CustomParticle, are not affected. - Applications using QWindow and QOpenGLContext and not Qt Quick are also not affected. - Covers are unaffected. Only applications using Qt Quick, QSG-classes and/or QOpenGLContext and/or raw OpenGL calls ARE affected. If this applies to you, there are two ways to deal with graphics stuff being released: 1. Don't allow releasing. This is a valid scenario in many cases. Shaders have been compiled, resources loaded, etc and rebuilding this is difficult, take too long to be feasible or some times not possible at all. If so, add the following two lines to your main.cpp AFTER you told it to load the QML file and BEFORE you show it. QQuickWindow::setPersistentSceneGraph(true); QQuickWindow::setPersistentOpenGL(true); This will revert to the current behaviour where graphics resources are retained, even when the application is backgrounded. 2. React and handle it. Use the QQuickWindow::sceneGraphInvalidated() and QOpenGLContext::aboutToBeDestroyed() signals to clean up your graphics resources and let your application handle not being shown on screen. --- I can't tell you when the change over happens, but we're aiming for some time later this year :) I'm giving you an early heads up so you can update your applications now if you are affected. Reacting to http://qt-project.org/doc/qt-5/qquickwindow.html#sceneGraphInvalidated or http://qt-project.org/doc/qt-5/qopenglcontext.html#aboutToBeDestroyed is something something you can already do. Same if you want to avoid the issue all together and setPersistent(SceneGraph|OpenGL)(true) right away. These APIs have been there since Qt 5.0. --- If you have further questions, please feel free to ask. cheers, Gunnar (sletta on IRC) ___ SailfishOS.org Devel mailing list
