Closed
Bug 1229853
Opened 9 years ago
Closed 9 years ago
Root container layer on Fennec has a big low-res displayport for no reason
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
mozilla45
Tracking | Status | |
---|---|---|
firefox45 | --- | fixed |
People
(Reporter: kats, Assigned: kats)
References
Details
Attachments
(1 file)
(deleted),
patch
|
tnikkel
:
review+
|
Details | Diff | Splinter Review |
I was investigating some of the talos regression with Fennec switched over to the C++ APZ and noticed that the root container layer on Fennec has a bogus low-res displayport. This is what it used to be before APZ:
ContainerLayerComposite (0x832e8000) [shadow-visible=< (x=0, y=0, w=768, h=1038); >] [visible=< (x=0, y=0, w=768, h=1038); >] [metrics0={ [cb=(x=0.000000, y=0.000000, w=768.000000, h=1038.000000)] [sr=(x=0.000000, y=0.000000, w=384.000000, h=519.000000)] [s=(0,0)] [dp=(x=0.000000, y=0.000000, w=0.000000, h=0.000000)] [cdp=(x=0.000000, y=0.000000, w=0.000000, h=0.000000)] [color=rgba(0, 0, 0, 0.000000)] [scrollId=0] [z=2] }]
This is what it is with APZ:
ContainerLayerComposite (0x89d64c00) [shadow-visible=< (x=0, y=0, w=768, h=1038); >] [visible=< (x=0, y=0, w=768, h=1038); >] [metrics0={ [cb=(x=0.000000, y=0.000000, w=768.000000, h=1038.000000)] [sr=(x=0.000000, y=0.000000, w=384.000000, h=519.000000)] [s=(0,0)] [dp=(x=-576.000000, y=-778.500000, w=1536.000000, h=2076.000000)] [cdp=(x=0.000000, y=0.000000, w=384.000000, h=519.000000)] [color=rgba(0, 0, 0, 0.000000)] [scrollId=2] [z=2] }]
Note that the "dp" value is pretty large and exceeds the scrollable rect. I looked into why this was happening and it's because there is no root scrollable frame for the root document in Fennec. So we end up applying the low-res multiplier at [1] without the clamping that would normally happen at [2].
[1] https://dxr.mozilla.org/mozilla-central/rev/470f4f8c2b2d6f82e56e161a4b05262c85f55b59/layout/base/nsLayoutUtils.cpp#906
[2] https://dxr.mozilla.org/mozilla-central/rev/470f4f8c2b2d6f82e56e161a4b05262c85f55b59/layout/base/nsLayoutUtils.cpp#1031
Assignee | ||
Comment 1•9 years ago
|
||
Not sure if this will actually make any difference but I don't think there is much point to applying the multiplier in these cases.
Attachment #8694834 -
Flags: review?(tnikkel)
Assignee | ||
Comment 2•9 years ago
|
||
Comment 3•9 years ago
|
||
Comment on attachment 8694834 [details] [diff] [review]
Patch
> if (!frame) {
> // Turns out we can't really compute it. Oops. We still should return
> // something sane. Note that although we can apply the multiplier on the
> // base rect here, we can't tile-align or clamp the rect without a frame.
> NS_WARNING("Attempting to get a displayport from a content with no primary frame!");
>- return ApplyRectMultiplier(base, aMultiplier);
>+ return base;
> }
Can you update the comment here too?
Attachment #8694834 -
Flags: review?(tnikkel) → review+
Comment 5•9 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
You need to log in
before you can comment on or make changes to this bug.
Description
•