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

Status: RESOLVED FIXED

(Core Graveyard :: Widget: Android, defect)

Description

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch to introduce and use AutoJObject

Comment 1

[Kartikaya Gupta (email:[e-mail])]

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?

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

(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.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a1c6277222bb