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

Status: RESOLVED FIXED

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

Description

[Trevor Skywalker]

This bug was filed from the Socorro interface and is 
report bp-f07ca18b-31aa-407d-9e72-d122a0170418.
=============================================================

Comment 1

[Trevor Skywalker]

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.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 3

[Trevor Skywalker]

Do these help?

Report ID 	Date Submitted
bp-0165acf3-c6b6-4efc-aa4a-8593c0170418
	04/18/2017	05:21:45
bp-59900f99-83f8-4b1b-aa3a-568920170418
	04/18/2017	05:20:20
bp-7ef53d60-9188-452f-8b31-88d9a0170418
	04/18/2017	05:17:22
bp-2afbc08a-b1a0-4ab8-af59-fd3250170418
	04/18/2017	05:17:08
bp-0bfd0d2f-0144-4aa9-bb17-17ebd0170418
	04/18/2017	05:15:01
bp-f07ca18b-31aa-407d-9e72-d122a0170418
	04/18/2017	05:00:52
bp-e2a8a25d-d2b2-4776-ba58-397050170418
	04/18/2017	05:00:34
bp-f7801a44-6e83-4c06-9763-3c4760170418
	04/18/2017	04:52:02
bp-bb7e30b8-6106-4510-85b4-cb4010170418
	04/18/2017	04:49:57
bp-44d569e5-bad4-4738-8a9e-6b3b30170418
	04/18/2017	04:36:35
bp-100a03ff-93c6-4f9d-86ce-a45a90170418
	04/18/2017	04:36:08
bp-b860229d-2fc9-476a-8659-f18fc0170418
	04/18/2017	04:35:27
bp-17d49fff-4cb6-4838-9dc8-315b10170418
	04/18/2017	04:34:53
bp-ef7f271d-ba68-4284-a019-980f80170418
	04/18/2017	04:33:58
bp-9dffd053-9d91-4391-9ccb-c569a0170418
	04/18/2017	04:33:43
bp-93566be4-f276-4d7c-9ece-56e310170418
	04/18/2017	04:11:07

Comment 4

[Jamie Nicol [: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.

Comment 5

[Jamie Nicol [:jnicol]]

Attachment: testcase.html

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.

Comment 6

[Jamie Nicol [:jnicol]]

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.

Comment 7

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

per https://bugzilla.mozilla.org/show_bug.cgi?id=1041968#c37

Comment 8

[Gerry Chang [:gchang]]

Track 54+/55+ as the volume of crashes is high.

Comment 9

[Gerry Chang [:gchang]]

Mark 54 won't fix as 54 was released.

Comment 10

[Wayne Mery (:wsmwk)]

Trevor, can you still reproduce?

Comment 11

[Wayne Mery (:wsmwk)]

(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

Comment 12

[Jamie Nicol [:jnicol]]

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