Affected versions

• 66.0.5, 67.0b19, 68.0a1 (2019-05-13);

Affected platforms

• Windows 10, macOS 10.13, Ubuntu 18.04;

Steps to reproduce

1. Access https://sketchfab.com/3d-models/mythcreature-round-4-3d-editor-with-sound-571ef25a0bcd4972bcb941098edc85b4
2. Wait for the model to load;
3. Click on the sketchfab_Home button;

Expected result

• homepage loads without any issues;

Actual result

• for a few seconds the page loads without the css rules applied;

Regression range

• First bad build_date: 2018-04-18; changeset: a0c804993efc599a95e97bea39fa1528fd0195d8;
• Last good build_date: 2018-04-17; changeset: 789e30ff2e3d6e1fcfce1a373c1e5635488d24da;
• Pushlog: link

Additional notes

• attached recording with the issue;
• issue reproduces on the initial load even for just the homepage;

Setting the STR flag as irrelevant since the issue manifests when accessing the homepage - https://sketchfab.com

confirmed but this is a bug spanning multiple past releases so wontfix for 66/67

Profile: https://perfht.ml/2E7eE3y

dholbert: can you take a look?

I can't reproduce from the Mountain View office, for what it's worth.

A few observations:

• It looks like "https://static.sketchfab.com/static/builds/web/dist/website-style-c99cf329f1a7c3cd6a77.css" is the relevant stylesheet that provides the missing styles here. (If I view the page and then use devtools to delete that stylesheet, then I end up looking at an unstyled-looking page, like the one in the screencast & the profile's screenshots track.)

• Looking at the "network" track in the profiler, it looks like that stylesheet takes 199ms to download, and it finishes downloading quite early (not long after our first paint of unstyled content), at around the 7.75 second mark in the profile: https://perfht.ml/30mSkwm

• After that stylesheet loads, it doesn't affect the rendering right away, in part because we seem to be a bit starved for RefreshDriver ticks -- maybe 2/3 of a second goes by between the download and our next RefreshDriver tick beginning, based on the marker chart: https://perfht.ml/30tnUIO

• That RefreshDriver tick is where we get to repaint to show the results of this new stylesheet, and the paint (green "Rasterize" bar) is quite long -- 325ms, around 1/3 of a second: https://perfht.ml/30jTEjs

So with the RefreshDriver tick delay (over a half second) combined with the slow paint during the tick (around 1/3 second), combined with some JS, we end up stuck with the initial unstyled-content rendering for a little over a second before our next paint makes it to the screen.

Vicky: is there any chance you could profile with a lower sample interval? In your profile, it looks like the samples are 100ms in size, which is pretty huge. (I'm used to seeing profiles with samples being in the 0.2ms - 2ms range, not 100ms)

Sorry! I had mine turned up to lower overhead to just get markers previously.

FWIW, if I had to fiddle with the model a little bit in order to get the missing stylesheet.

New profile with 1ms samples: https://perfht.ml/2E6jQVa

So that new profile seems to be showing unstyled content for ~960ms.

Most of that time is spent on a 656ms Rasterize operation, which seems to be spending its time in mozilla::layers::ShmemTextureData::Create (in 2 separate calls, I think, each of which take >300ms).

So, that's where the perf issue seems to lie. --> Moving to Graphics::Layers.

At least for the specific page in comment 0, I'd wager that one of the slow ShmemTextureData::Create calls is for this <img> element which is ~15000px wide:

<img
 src="https://media.sketchfab.com/urls/571ef25a0bcd4972bcb941098edc85b4/dist/fallback/3d53aeb1f2cb4d3bbeb28071f11948eb/355d5c7757934de7be1a4e428dfdf1e4.jpeg"
 alt="" class="fallback-sprite" style="display: block;">

(The image's intrinsic dimensions are 19200 by 720, but it's sized to fit its container with height:100%, and its container isn't quite 720px tall for me so it ends up rendering at something less than 19200px wide -- but still pretty huge.)

You can't see the whole image when you're viewing the page, because it's inside of several layers of overflow:hidden containers, but it does exist in the DOM and we probably do presumably create a ~15000px-wide layer for it.

When the bug reproduces, it seems we're unlucky enough that the first "styled" paint (first paint after website-style-c99cf329f1a7c3cd6a77.css has loaded) happens to be the first paint where this image is available, so everything gets held up on allocating surfaces for this image.

Jamie, that sounds like a layers heuristic issue, what do you think?

Hmm, I can't reproduce this. It flashes unstyled very briefly for me, nothing like hundreds of milliseconds I don't think. I'm also not seeing ShmemTextureData::Create being called for any suspiciously large sizes.

Cristi or Vicky, could you please reproduce with layout.display-list.dump-content=true, and attach the log. Thanks.

Attached the log, scenario: accessing the homepage from the browser's AS page.

Sorry I meant the output from the terminal which firefox is ran from, not the browser console log.

--DOMWINDOW == 12 (0000023FFACEC400) [pid = 13108] [serial = 15] [outer = 0000000000000000] [url = about:blank]
--DOCSHELL 0000023FF9108800 == 5 [pid = 13108] [id = {37e40427-a891-4034-b032-22c449c2edbb}] [url = about:config]

Bulk change of P3 carryover bugs to wontfix for 68.

Hi Cristi - could you test one more time, but with the pref that jnicol mentioned in comment 9? (at about:config, set "layout.display-list.dump-content" to "true"). Once that pref has been flipped, you should see lots of logging start appearing in your terminal (mentioning things like BasicLayerManager, BasicPaintedLayer, BasicContainerLayer, etc.)

There will be a lot of output, so if possible, it might be best to best to toggle the pref, then quit Firefox, and then start Firefox again with the stderr output being redirected into a file, e.g.

firefox https://sketchfab.com/3d-models/mythcreature-round-4-3d-editor-with-sound-571ef25a0bcd4972bcb941098edc85b4 2>log.txt

(using 2> to specifically capture stderr, since that's where this logging appears, for me at least).

Copy pasted directly from the console output for a asan-debug build off of taskcluster(directly accessing the homepage).

jnicol, can you glean anything from Cristi's log?

Unfortunately it doesn't contain any of the display list information. This could possibly be because it was ran on windows, where I've personally never been able to see stderr output from child processes, even though I know others can. Cristi, are you running on Windows?

The last log was from an asan-debug build on Linux.

Oh, my mistake, I must have got my tabs confused when I thought I'd been reading the log you posted. That does indeed contain the display list dump! Let me have a proper look at it now then

I don't see any layers in their which would be causing a large allocation. The log does seem fairly short, like the beginning is cut off - does your terminal have limited scrollback? Could you try Daniel's suggestion in comment 14 with 2>log.txt