Closed Bug 812594 Opened 7 years ago Closed 7 years ago

PushLocalFrame in AutoLocalJNIFrame::Push taking more than 100ms when called from AndroidGeckoLayerClient::ProgressiveUpdateCallback on a Samsung Galaxy Q

Categories

(Core :: Widget: Android, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla19

People

(Reporter: blassey, Assigned: blassey)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

No description provided.
Attachment #682576 - Flags: review?(bugmail.mozilla)
Comment on attachment 682576 [details] [diff] [review]
patch to introduce and use AutoJObject

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

This looks fine. Do you know why AutoLocalJNIFrame::Push is so high in this case but not others? Or is it high everywhere?
Attachment #682576 - Flags: review?(bugmail.mozilla) → review+
(In reply to Kartikaya Gupta (:kats) from comment #1)
> Comment on attachment 682576 [details] [diff] [review]
> patch to introduce and use AutoJObject
> 
> Review of attachment 682576 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This looks fine. Do you know why AutoLocalJNIFrame::Push is so high in this
> case but not others? Or is it high everywhere?

It is due to lock contention, so it can be high anywhere. But I suspect it is more likely to be high here because both the gecko thread and the compositor thread are busy during panning and they are contending for the same lock.
https://hg.mozilla.org/mozilla-central/rev/a1c6277222bb
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Assignee: nobody → blassey.bugs
You need to log in before you can comment on or make changes to this bug.