I don't have hard data on this aside from my dump statements but it looks like we can shave off about 300-900ms on the time it takes to generate the first preview by initializing the hardware while parsing the dom ( by using a seperate js file not deferred before the css )... See my hack: https://github.com/lightsofapollo/gaia/compare/start-camera-init-really-early
Whiteboard: [fast:300ms-900ms] → [fast:300ms-900ms], [FFOS_perf]
Dale, can you investigate on this and give us feedback to decide for blocking or not ?
I think this is a good idea, the hardware abstraction was planned anyway since the camera API became somewhat unweildy and needs to be seperated. And my testing is similiar to James's, I will still need to test with everything fully working but it looks like around a 400ms speedup (and an extra 3/400ms with the async storage change) Which are both significant speedups with not very intrusive changes, I will have both patches done tonight and suggest this blocks Cheers James for investigating.
Okay, we'll block on this. Please give us a heads up if your fix(es) end up with the potential for serious regressions. Thanks.
blocking-b2g: tef? → tef+
Marking status-b2g18 and status-b2g18-v1.0.0 as affected, please update the status to fixed once this is verified landed on v1-train/mozilla-b2g18 and v1.0.0/mozilla-b2g18_v_1_0_0
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → affected
Dale, any update ?
I am going to do more experimenting, but I dont believe there are significant gains in this approach anymore. I was seeing times around 150ms for parsing assets, and initialising the hardware early doesnt necessarily means it will be ready earlier. https://bugzilla.mozilla.org/show_bug.cgi?id=821695 is much more important, working on that now
No longer blocking based on comment 6 and the doubt that we'll get huge wins here. Re-nom if that changes.
blocking-b2g: tef+ → -
Batch edit: Bugs marked status-b2g18: affected after 2/13 branching of v1.0.1 are now also status-b2g18-v1.0.1: affected
status-b2g18-v1.0.1: --- → affected
Dale will provide a patch in few hours.
Created attachment 721895 [details] Github PR
Comment on attachment 721895 [details] Github PR https://github.com/mozilla-b2g/gaia/commit/1f7dbc2534914620ba05126e99eb47991de758e6
Attachment #721895 - Flags: review?(21) → review+
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
tef? if we want this on 1.0.1 for bug 817051.
blocking-b2g: leo? → tef?
(John, can we get a v1.0.1 uplift please?)
(In reply to Michael Vines [:m1] [:evilmachines] from comment #14) > (John, can we get a v1.0.1 uplift please?) Still waiting on 841251 for v1.0.1 v1-train: 0542a2f3c2f33274a90082011a13ef5d8a8c315f
status-b2g18: affected → fixed
status-b2g18-v1.0.0: affected → wontfix
John, sorry for the mess.. Bug 841251 is not in v1-train yet :(
Backed out as 42fb0a150b45ede69a51dd73af3a04ea1c7717b0
status-b2g18: fixed → affected
Uplifted commit 1f7dbc2534914620ba05126e99eb47991de758e6 as: v1-train: d0eeb90cddbdedd3c521d42f86a97ef33941d487 v1.0.1: 947a6cb04f500acaabb36d252c6464ea6475556d
status-b2g18: affected → fixed
status-b2g18-v1.0.1: affected → fixed
Does not make sense to create a regression issue.
Can you please provide steps to verify this fix - as we will blackbox test from the UI?
There was no functional change so I dont understand what steps to verify would be except that the app is as functional as it previously was
Verified fixed per comment 22.
Status: RESOLVED → VERIFIED
Probably best tested with datazilla.
Whiteboard: [fast:300ms-900ms], [FFOS_perf] → [fast:300ms-900ms], [FFOS_perf], [qa-]
You need to log in before you can comment on or make changes to this bug.