Open Bug 1827720 Opened 2 years ago Updated 1 year ago

Runaway RAM usage on https://emojipedia.org/microsoft-teams/

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Type:
defect

Tracking

()

People

(Reporter: twisniewski, Unassigned)

References

(
URL
)

Details

As reported in https://webcompat.com/issues/119025, Firefox seems to use a lot of memory and potential CPU spikes on pages with lots of animated images, such as https://tenor.com and https://emojipedia.org/microsoft-teams/ .

I've taken two performance profiles where I see their inverted stacks showing that the bulk of the time is spent painting, which isn't surprising (tenor.com, Emojipedia )

It's unclear to me if there is anything which can be done here, but Chrome does seem to handle these pages more smoothly and without the RAM steadily climbing as high.

Hmm, for https://emojipedia.org/microsoft-teams/ it looks like most of the time is because the loading image animation is hitting fallback mode, I wonder why.

I get a slightly different profile: https://share.firefox.dev/3UyNUPk

(In reply to Timothy Nikkel (:tnikkel) from comment #2)

Hmm, for https://emojipedia.org/microsoft-teams/ it looks like most of the time is because the loading image animation is hitting fallback mode, I wonder why.

Oh wait, of course, that is because it's an animated vector image, those have to fallback at the moment, svg blob images (bug 1811212) should help with that.

(In reply to Mayank Bansal from comment #3)

I get a slightly different profile: https://share.firefox.dev/3UyNUPk

That profile is quite different from comment 0 and what I see, and it looks like a memory report was being generated during this profile??

(In reply to Thomas Wisniewski [:twisniewski] from comment #0)

I've taken two performance profiles where I see their inverted stacks showing that the bulk of the time is spent painting, which isn't surprising (tenor.com, Emojipedia )

The tenor profile is quite different, most of the time is spent in JS. After js we spend the most time drawing the altfeedback for images. Maybe we should seperate these two sites as they look like they are tickling different areas.

Also, both these profiles have screenshots enabled, which skews graphics related things in the profile.

Sure, we can definitely split them up into separate bugs if it's more useful that way. I just took two fresh profiles with the Graphics setting and I do see the painting in inverted stacks is only 20% this time on tenor.com, so maybe there's something else there.

Tenor: https://share.firefox.dev/400Ycc1
Emojipedia: https://share.firefox.dev/3zVzmzM

(In reply to Thomas Wisniewski [:twisniewski] from comment #7)

Sure, we can definitely split them up into separate bugs if it's more useful that way. I just took two fresh profiles with the Graphics setting and I do see the painting in inverted stacks is only 20% this time on tenor.com, so maybe there's something else there.

Tenor: https://share.firefox.dev/400Ycc1
Emojipedia: https://share.firefox.dev/3zVzmzM

Yeah, the tenor one is mostly js execution, looks like a different kind of issue from the emojipedia one. The other chunk of tenor is drawing the text for the all feedback of the images, which is somewhat surprising to me, I would expect that to be quite quick. We should split the tenor one off to another bug (or the other way around).

Ok, I've filed bug 1827899 for the tenor.com issue, and changed the title of this bug.

Summary: RAM and CPU performance issues related to painting many animated images on long-scrolling pages → Runaway RAM usage on https://emojipedia.org/microsoft-teams/

The memory use is basically determined by the prefs
image.animated.decode-on-demand.threshold-kb
image.animated.decode-on-demand.batch-size

The threshold is the size in kb of pixel data before we start discarding frames, ie images with less than the threshold we keep around all decoded frames. And the batch-size is for images above the threshold, how many frames we keep decoded. Decreasing those prefs will bring us down, but not as small as Chrome, I think they just decode the frame of the image on their tick.

See Also: → 1827899

The severity field is not set for this bug.
:tnikkel, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(tnikkel)
Flags: needinfo?(tnikkel)
Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.