Closed Bug 1200729 Opened 6 years ago Closed 6 years ago

Low-res Displayport has regressed on Fennec nightly


(Core :: Graphics: Layers, defect)

Not set



Tracking Status
firefox40 --- unaffected
firefox41 --- unaffected
firefox42 + fixed
firefox43 + fixed
fennec 42+ ---


(Reporter: BenWa, Assigned: jnicol)



(Keywords: regression, reproducible, Whiteboard: gfx-noted)


(1 file)

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.
Whiteboard: gfx-noted
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:

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:
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+.
Assignee: bugmail.mozilla → nobody
Blocks: 1176077
tracking-fennec: 43+ → ?
Tracking for 42+. Thanks for the regression range finding! 

Jamie, can you take a look?
Flags: needinfo?(jnicol)
I'm on the case.
Assignee: nobody → jnicol
Flags: needinfo?(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.
tracking-fennec: ? → 42+
Attached patch Patch v1Splinter Review
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 -

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 ( so requesting checkin for the patch

Will now test on 42.
Keywords: checkin-needed
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?
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
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.