Closed
Bug 1034283
Opened 10 years ago
Closed 9 years ago
Overdraw counter weirdness
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: milan, Assigned: BenWa)
References
(Depends on 1 open bug)
Details
Attachments
(2 files)
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.
Reporter | ||
Comment 1•10 years ago
|
||
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?
Reporter | ||
Comment 2•10 years ago
|
||
Reporter | ||
Comment 3•10 years ago
|
||
Reporter | ||
Comment 4•10 years ago
|
||
(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.
Reporter | ||
Updated•10 years ago
|
Reporter | ||
Updated•10 years ago
|
Assignee: nobody → bgirard
Assignee | ||
Comment 5•10 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
Reporter | ||
Comment 6•10 years ago
|
||
All that extra work in the compositor isn't interfering with the async animation?
Comment 7•10 years ago
|
||
NI, can you please help make a decision blocking/non-blocking here ?
Flags: needinfo?(milan)
Reporter | ||
Comment 8•10 years ago
|
||
I will leave it as not blocking until we're sure otherwise.
blocking-b2g: 2.0? → ---
Flags: needinfo?(milan)
Comment 9•10 years ago
|
||
Are we also painting offscreen? That seems terrible.
Reporter | ||
Comment 10•10 years ago
|
||
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)
Reporter | ||
Comment 11•9 years ago
|
||
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
Closed: 9 years ago
Flags: needinfo?(milan)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•