Closed Bug 915120 Opened 6 years ago Closed 6 years ago
.2] Regression in Settings Scroll FPS (compared to [1 .1]
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36 Steps to reproduce: Based on high speed camera measurements (on a QRD 7x27 device), there seems to be a degradation in UX scroll performance of the Settings App. Actual results: Measurements on 1.2: 50 FPS Measurements on 1.1: 57 FPS
Severity: normal → blocker
blocking-b2g: --- → koi?
Depends on: 914906
OS: All → Gonk (Firefox OS)
Priority: -- → P1
Severity: blocker → critical
blocking-b2g: koi? → koi+
Per Sandip on bug 914906: Minimum Expected Benchmark for Settings App Scrolling is 55 FPS.
Here's a screenshot of the relevant part of this profile: http://people.mozilla.org/~bgirard/cleopatra/#report=c1319924bbdf5c9bc60994789a23475c537e4291 This shows that we're missing our frame budget because of buffer rotation!
Benoit - from your chat on IRC it looks like bug 916626 could be related. Can you verify?
Depends on: 916626
(In reply to Kevin Grandon :kgrandon from comment #4) > Benoit - from your chat on IRC it looks like bug 916626 could be related. > Can you verify? Currently when we unrotate the buffer we allocate a new gralloc buffer, move our old data into the new buffer and throw the old one away. So the usage is temporary but if we're within one buffer (say 0.5MB pmem left) then will hit the limit. So yes it doesn't help but it's not a permanent buffer. Bug 917416 is an example of where we keep screensize pmem buffer around needlessly for a fullscreen app.
The graphics team is investigating un-rotating the buffer in place in a cache friendly manner. I'm working on a prototype at the moment.
Per Qualcomm's testing, the 1.1 regression has been solved. Please look at their report. Reported v1.1 FPS was 57, current testing is 55.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
(In reply to Benoit Girard (:BenWa) from comment #6) > The graphics team is investigating un-rotating the buffer in place in a > cache friendly manner. I'm working on a prototype at the moment. Let's open another bug for this.
We have clearly a bug here and that was not resolved. We merely had some unrelated wins that improved the total performance. A better resolution would have been to morph this bug into the issue BenWa observed (in-place buffer unrotation). Filing a new bug is fine, but please link it here.
Right - new bug makes more sense, because the buffer unrotate issue observed is not a regression.
You need to log in before you can comment on or make changes to this bug.