[SailfishDevel] Upcoming behavioural change with how graphics resources are handled.
Gunnar Sletta
gunnar at sletta.org
Thu Oct 2 06:47:51 UTC 2014
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 <Kimmo.Lindholm at eke.fi> 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 <mohammed.hassan at jolla.com> wrote:
>
>> On Sat, 27 Sep 2014 16:28:42 +0000
>> Kimmo Lindholm <Kimmo.Lindholm at eke.fi> 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-unsubscribe at lists.sailfishos.org
>
>
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe at lists.sailfishos.org
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe at lists.sailfishos.org
More information about the Devel
mailing list