1034283 - Overdraw counter weirdness

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: Homescreen layer tree dump after restarting the phone

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: Homescreen layer tree dump after starting three apps

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 5

[Benoit Girard (:BenWa)]

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.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

All that extra work in the compositor isn't interfering with the async animation?

Comment 7

[bhavana bajaj [:bajaj]]

NI, can you please help make a decision blocking/non-blocking here ?

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

I will leave it as not blocking until we're sure otherwise.

Comment 9

[Andreas Gal :gal]

Are we also painting offscreen? That seems terrible.

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

This seems to be OK in the latest nightly.  As in, the overdraw number does not keep growing as we open more apps.