Closed Bug 1357359 Opened 7 years ago Closed 3 years ago

Crash in OOM | small on http://www.zpravy.cz/ on fennec

Categories

(Core :: Graphics: Layers, defect, P3)

Unspecified
Android
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox53 --- wontfix
firefox54 + wontfix
firefox55 + wontfix
firefox56 --- wontfix
firefox57 --- wontfix

People

(Reporter: skywalker333, Assigned: jnicol)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 obsolete file)

This bug was filed from the Socorro interface and is 
report bp-f07ca18b-31aa-407d-9e72-d122a0170418.
=============================================================
I am able to reproduce this crash on http://www.zpravy.cz/ by zooming in and out, scrolling, and rotating the display from portrait to landscape with Firefox for Android Beta 53.0b7.
Jamie, any thoughts here? I don't know if the "TextureUsage" metadata item in the crash report is actually measuring allocated texture usage but it seems pretty high.
Flags: needinfo?(jnicol)
I think that's allocated gl texture size in bytes, which is indeed high. The page is creating lots of painted layers. I will investigate why.
Assignee: nobody → jnicol
Flags: needinfo?(jnicol)
Attached file testcase.html (obsolete) —
Attached is a minimal test case reproducing the problem.

The timestamp for each article uses background-attachment:fixed to render the gradient beneath the text. As I understand it this means that the Background display items should be fixed to the viewport but their clip should scroll with the main page. So FrameLayerBuilder adds the page's scrollable content (headlines, images,etc) to a PaintedLayerDataNode, then encounters a timestamp. The timestamp has a different AGR, so FrameLayerBuilder must finalise the Node which was in progress. Then it continues building another layer until it reaches another timestamp and must finalise that layer too. This results in far too many layers, causing high memory usage.

I think FrameLayerBuilder should be smart enough to realise that since the clip scrolls, the timestamps do not interfere with the layerisation of the page. It should pretend that it has the same AGR as the scrollable content. There is code for this in ProcessDisplayItems(). On desktop this happens, but on android it does not. I'm trying to figure out why.
Summary: Crash in OOM | small → Crash in OOM | small on http://www.zpravy.cz/ on fennec
See Also: → 1361354
Comment on attachment 8862923 [details]
testcase.html

My description in comment 5 isn't quite accurate, and the test case as wrong. The clipping was working correctly for the first 20 fixed positions. But once the layers.max-active limit was reached the fixed position backgrounds start to be rendered using inactive layers, which are not clipped correctly. This leads to the excessive layerization because of something similar to the reason described.

This was fixed in bug 1358185.

There is still a large issue, however: We need to be able to composite the correct parts of the background as the page is async scrolled. To do this each background is rendered in to a layer the size of the viewport. There are a lot of items with fixed position backgrounds, so this requires a very large amount of memory.
Attachment #8862923 - Attachment is obsolete: true
[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

per https://bugzilla.mozilla.org/show_bug.cgi?id=1041968#c37
Flags: needinfo?(gchang)
Track 54+/55+ as the volume of crashes is high.
Flags: needinfo?(gchang)
Mark 54 won't fix as 54 was released.
Has STR: --- → yes
See Also: → 1418816

Trevor, can you still reproduce?

Flags: needinfo?(skywalker333)
Component: Toolbar → Graphics: Layers
Product: Firefox for Android → Core

(In reply to Jamie Nicol [:jnicol] from comment #6)

There is still a large issue, however: We need to be able to composite the
correct parts of the background as the page is async scrolled. To do this
each background is rendered in to a layer the size of the viewport. There
are a lot of items with fixed position backgrounds, so this requires a very
large amount of memory.

Trevor apparently no longer available. But according to bug 1418816 comment 34 this is still an issue

Flags: needinfo?(skywalker333)

Note that this issue is fixed by webrender. It's unlikely that we'll ever fix this for layers.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.