Closed Bug 1200729 Opened 5 years ago Closed 5 years ago
Low-res Displayport has regressed on Fennec nightly
I'm no longer seeing a low-res displayport on Fennec nightly. This means that I instantly checkerboard when zomming out. A regressionwindow here would be nice to find the cause of this issue.
[Tracking Requested - why for this release]: Regressing a big feature, we should avoid shipping this or do so consciously.
tracking-fennec: --- → ?
Assignee: nobody → bugmail.mozilla
tracking-fennec: ? → 43+
Seems to have regressed between the 07-20 nightly and the 07-21 nightly, although I'm not 100% confident in that since sometimes it's hard to tell if this bug is manifesting or not. That range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5df788c56ae7&tochange=3a4bfa5d2d02 and there doesn't seem to be any particular culprit there. I'll try bisecting further with local builds.
I redid the nightly bisection and now think it regressed between 07-23 and 07-24. Again my confidence in this isn't high but I'm fairly sure the 07-25 build is bad. Here's the range for the 23rd to the 24th: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1f77b78797d6&tochange=b0b3dcfa5557
I did a further bisection into that range with local builds and I'm pretty sure this is a regression from bug 1176077. Re-requesting tracking since it affects 42 as well and should probably be 42+.
Tracking for 42+. Thanks for the regression range finding! Jamie, can you take a look?
I'm on the case.
Assignee: nobody → jnicol
What's happening here is that the first paint of the transaction is high precision, so the frame layer builder calculates which display items are visible based on the high-precision invalid region. Then we go to draw the low-precision stuff in repeat transactions, and this has a much larger invalid region needing drawn. But the frame layer builder has already decided that most of the items in this region are not visible since they fall outwith the high-precision invalid region.
I've decided to make the FrameLayerBuilder remember for what region it has calculated display item visibility, then recalculate it whenever that region changes. It seemed a better approach to me than making both the low and high res ClientMultiTiledLayerBuffers aware of the others one's invalid regions, or making the MultiTiledContentClient talk directly to the FrameLayerBuilder. Try run - https://treeherder.mozilla.org/#/jobs?repo=try&revision=baff58269e8b Matt, are you okay to review since you did my previous patches to do with this? (Comment 7 describes the problem)
Attachment #8661233 - Flags: review?(matt.woodrow)
Attachment #8661233 - Flags: review?(matt.woodrow) → review+
Try run looks good (https://treeherder.mozilla.org/#/jobs?repo=try&revision=ff6a8d601ded) so requesting checkin for the patch Will now test on 42.
Comment on attachment 8661233 [details] [diff] [review] Patch v1 Approval Request Comment [Feature/regressing bug #]: Low-res display port [User impact if declined]: Much worse user experience when scrolling or zooming out on android and b2g. [Describe test coverage new/current, TreeHerder]: Try run for nightly is in comment 8. I've verified manually it works on aurora. [Risks and why]: Low risk, fairly simple change. [String/UUID change made/needed]: None
Attachment #8661233 - Flags: approval-mozilla-aurora?
Comment on attachment 8661233 [details] [diff] [review] Patch v1 Fix a recent regression, taking it.
Attachment #8661233 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.