Closed Bug 1141311 Opened 9 years ago Closed 9 years ago

Add async mode support to GonkNativeWindow on Lollipop Gonk

Categories

(Core :: Graphics, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla39
blocking-b2g 2.2+
Tracking Status
firefox37 --- wontfix
firefox38 --- wontfix
firefox39 --- fixed
b2g-v2.2 --- fixed
b2g-master --- fixed

People

(Reporter: sotaro, Assigned: sotaro)

References

Details

Attachments

(1 file)

async mode is necessary to handle return nullprt from GonkNativeWindow::getCurrentBuffer() situation. It happen when gecko side hold more than GonkBufferQueue::mMaxAcquiredBufferCount+1 buffer.

Bug 1036539 added "Add async mode support" until KK.

In android, this should not happen. But on b2g this could happen.
If it happens, GonkBufferQueue always continue to hold one additional frame.
Assignee: nobody → sotaro.ikeda.g
See Also: → 1036539
(In reply to Sotaro Ikeda [:sotaro] from comment #0)
> 
> In android, this should not happen. But on b2g this could happen.
> If it happens, GonkBufferQueue always continue to hold one additional frame.


When we do not extend MaxAcquiredBufferCount by the following call, it is easily happen during WebRTC.
 > consumer->setMaxAcquiredBufferCount(WEBRTC_OMX_H264_MIN_DECODE_BUFFERS);
Blocks: 1137515
No longer depends on: 1137515
Nominate this case as "2.2?" for triage.

--
Keven
blocking-b2g: --- → 2.2?
(In reply to Sotaro Ikeda [:sotaro] from comment #0)
> async mode is necessary to handle return nullprt from
> GonkNativeWindow::getCurrentBuffer() situation. It happen when gecko side
> hold more than GonkBufferQueue::mMaxAcquiredBufferCount+1 buffer.

Each time when it happens, GonkBufferQueue accumulate one more buffer in the GonkBufferQueue.
Hi Sotaro, what would be the user implication of this bug on 2.2?  Would it simply consume more memory than it needs to?  Just want to know about its priority level. thanks!
Flags: needinfo?(sotaro.ikeda.g)
(In reply to No-Jun Park [:njpark] from comment #4)
> Hi Sotaro, what would be the user implication of this bug on 2.2?  Would it
> simply consume more memory than it needs to?  Just want to know about its
> priority level. thanks!

camera preview stream add more lags. It affect to the camera preview's responsiveness. And If GonkNativeWindow accumulate too much video frame, it could block camera preview update.
Flags: needinfo?(sotaro.ikeda.g)
Attachment #8575392 - Flags: review?(pchang)
Comment on attachment 8575392 [details] [diff] [review]
patch -  Add async mode support to GonkNativeWindow on Lollipop Gonk

Review of attachment 8575392 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM
Attachment #8575392 - Flags: review?(pchang) → review+
Blocks: 1098970
Status: NEW → ASSIGNED
blocking-b2g: 2.2? → 2.2+
https://hg.mozilla.org/mozilla-central/rev/583d27938297
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Comment on attachment 8575392 [details] [diff] [review]
patch -  Add async mode support to GonkNativeWindow on Lollipop Gonk

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): none
User impact if declined: User could face a lag of camera preview during WebRTC.
Testing completed: locally tested.
Risk to taking this patch (and alternatives if risky): low.
String or UUID changes made by this patch: none.
Attachment #8575392 - Flags: approval-mozilla-b2g37?
Attachment #8575392 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: