Screen wake lock while scanning media files?

[David Flanagan]

Dev Gaians,

Recently (for bug 963917) I realized that when the Gallery app needed to
scan thousands of images on the sdcard, the screen was timing out and
blanking before it could complete the scan. When the screen blanked,
the app would become a background app. And becasue scanning images is
very memory intensive, the app apparently ends up being killed because
of low memory.

I found that if I use navigator.requestWakeLock('screen') when scanning
starts (and then release the lock when scanning ends) I can prevent this
OOM and allow the gallery to finish scanning even when there are many
photos to scan.

It is unclear to me, however, whether this is the right thing to do, or
whether it is just a workaround for a bug in the platform. That is,
maybe the foreground app should remain in the foreground even when the
screen sleeps?

It seems wrong that I have to keep the screen turned on in order to scan
the media files. Is there a way to finesse this? Perhaps if an app
requests a CPU lock then it should stay as a foreground app even when
the screen blanks?

David

[Julien Wajsberg]

Maybe you can do the same with another WakeLock ?

var wakeLock = navigator.requestWakeLock('cpu');

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia

[David Flanagan]

On 2/4/14 2:57 AM, Julien Wajsberg wrote:
> Maybe you can do the same with another WakeLock ?
>
> var wakeLock = navigator.requestWakeLock('cpu');
>

Yes, that is what I would like to do... see my last paragraph below.

I've tried it, though, and it does not prevent my app from going to the
background and getting killed when the screen blanks.

Dave Hylands pointed out that this is probably the same situation as bug
852925, so I've updated that bug. Let's take the discussion there. We
now have two use cases for fixing this bug: contact imports and media
file scanning.

David

[Tim Chien]

There is no way to prevent that.

Screen lock or CPU lock has nothing to do with visibility state. User
is always allowed to press home to hide the app and press the hardware
sleep/power key to turn off the screen.

Screen lock simply stops system app from automatically turning off the
screen, e.g. for video/monitoring app.
CPU lock simply stop the phone from suspending JavaScript execution
cycles when the screen is asleep.

Maybe we should decouple visibility state and OOM when the screen is
turned off, and keep the original OOM scores? Not sure how hard it
would be for platform to implement.

(Didn't realize there is a thread here so I am copying my
https://bugzilla.mozilla.org/show_bug.cgi?id=963917#c81)

--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)

[Alive]

Tim Chien <timd...@mozilla.com> 於 2014/2/5 上午10:00 寫道：
>
> Maybe we should decouple visibility state and OOM when the screen is
> turned off, and keep the original OOM scores? Not sure how hard it
> would be for platform to implement.

Page visibility has heavy responsibility.

+1 For decoupling ProcessPriority with PageVisibility.
We are working on decoupling PageVisibility with AudioCompetingPolicy,
and the OOM score is some another thing I hope we could control from gaia system app -- for more flexibility --
but :fabrice dislikes that :)

BTW, if ProcessPriorityManager is able to know the screen lock state of each app maybe we could fix this issue.
Should we open a bug for this?

We already have a bug talking about letting ProcessPriorityManager to consider web activity relationship between apps instead of just using page visibility..

Alive C. Kuo, Senior Front-end/Software Engineer, FirefoxOS, MoCo. Taiwan, Taipei office.
al...@mozilla.com

[Vivien Nicolas]

On 05/02/2014 10:57, Alive wrote:
>
> Tim Chien <timd...@mozilla.com> 於 2014/2/5 上午10:00 寫道：
>>
>> Maybe we should decouple visibility state and OOM when the screen is
>> turned off, and keep the original OOM scores? Not sure how hard it
>> would be for platform to implement.
>
> Page visibility has heavy responsibility.
>
> +1 For decoupling ProcessPriority with PageVisibility.
> We are working on decoupling PageVisibility with AudioCompetingPolicy,
> and the OOM score is some another thing I hope we could control from gaia system app -- for more flexibility --
> but :fabrice dislikes that :)

+1 to have some heuristics in Gaia to adjust the OOM score. Decoupling
page visibility and Process priority scares me a little bit though.

[Fabrice Desré]

On 02/05/2014 01:00 AM, Tim Chien wrote:
> CPU lock simply stop the phone from suspending JavaScript execution
> cycles when the screen is asleep.

That's not true. We use that to set the process priority, see
https://mxr.mozilla.org/mozilla-central/source/dom/ipc/ProcessPriorityManager.cpp#902

Note that there is also the "High Priority" wake lock that could be
useful there. You can set it with
navigator.requestWakeLock('high-priority');

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[David Flanagan]

Thanks for this info, Fabrice! I tried CPU lock but found that it did
not prevent the Gallery app from being killed when the screen timed out
and went blank. Would you consider that a bug?

I did not know about the 'high-priority' option. If that solves the
problem, I should probably just modify mediadb to use that while
scanning so that all of our media apps will benefit from it.

I've pasted your message into bug 852925 because it seems like it might
be relevant there.

David