Overdraw counter weirdness

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: milan, Assigned: BenWa)

Tracking

(Depends on: 1 bug)

26 Branch
x86
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Either the counter is wrong or we're doing something really strange.

On B2G 2.1
* Reboot.
* Enable the FPS counter in developer prefs.
* Keep an eye on the third number.
* Scroll the home screen.
At this point, I'm seeing numbers 300+, just dipping to 299 at the very bottom of the home screen.

* Start phone app, go back to home screen.  I'm now seeing 400+ (slightly lower at the bottom).
* Start messages app, go back to home screen.  500+.
* Start contacts app, go back to home screen.  600+.

You get the picture.
Please leave this in triage (2.0?) until we figure out if the counter is wrong, or if the layer tree is too complicated.  Either way, we look at those numbers too much to have them be unreliable, or if they are reliable, something nasty is going on.
blocking-b2g: --- → 2.0?
Created attachment 8450538 [details]
Homescreen layer tree dump after restarting the phone
Created attachment 8450539 [details]
Homescreen layer tree dump after starting three apps
(In reply to Milan Sreckovic [:milan] from comment #3)
> Created attachment 8450539 [details]
> Homescreen layer tree dump after starting three apps

Note this one has the layer tree twice in the file, cut and paste error.
Assignee: nobody → bgirard
(Assignee)

Comment 5

4 years ago
Looks like we're retaining the apps as layer. This is great if we care about the latency to start the swipe animation but I don't think these devices really have enough memory for us to be retaining this so aggressively.

From the layer tree it looks like we're compositing these layers offscreen. We're sending draw calls for them but the driver shouldn't consume any memory bandwidth so it's not as big of an issue.

Bug 916270 has some effort to make the fill counter a better estimate.
Depends on: 916270
All that extra work in the compositor isn't interfering with the async animation?
NI, can you please help make a decision blocking/non-blocking here ?
Flags: needinfo?(milan)
I will leave it as not blocking until we're sure otherwise.
blocking-b2g: 2.0? → ---
Flags: needinfo?(milan)

Comment 9

4 years ago
Are we also painting offscreen? That seems terrible.
Right - the individual causes for this high overdraw number ended up getting handled in bug 1027231, bug 1022164 and bug 1034347; this ended up mutating more into a "improve the estimate for the overdraw" bug.  I'm still going to track it to see what happens when these others are resolved.
As far as painting - this was more of a compositing issue; things were hanging around because of will-change.
Flags: needinfo?(milan)
This seems to be OK in the latest nightly.  As in, the overdraw number does not keep growing as we open more apps.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(milan)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.