1429728 - 50%+ CPU usage on newyorker.com with completely covered animated image

Status: NEW

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

Description

[Tim Taubert [:ttaubert] (inactive)]

https://www.newyorker.com/magazine/2018/01/15/when-deportation-is-a-death-sentence

The above web page has a subtly animated header image. On my rMBP that leads to 50%+ CPU usage when looking at the page. When it's loaded in a background tab it consumes 25-30% constantly.

The compositor seems to be busy all the time.

https://perfht.ml/2D4b22T

Comment 1

[Markus Stange [:mstange]]

The compositor being busy is not a surprise, because the video updates all the time. But that should only translate into GPU usage, not into CPU usage.

The main thread is busy because every refresh tick causes the display list to be rebuilt, it seems like this is due to an animated image (*not* the video):

    mozilla::PresShell::ScheduleViewManagerFlush(nsIPresShell::PaintType)
    nsIFrame::SchedulePaint(nsIFrame::PaintType, bool)
    mozilla::css::InvalidateImages(nsIFrame*)
    mozilla::css::ImageLoader::DoRedraw(nsTArray<nsIFrame*>*, bool)
    mozilla::css::ImageLoader::Notify(imgIRequest*, int, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*)
    imgRequestProxy::Notify(int, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*)
    void mozilla::image::SyncNotifyInternal<mozilla::image::ObserverTable const*>(mozilla::image::ObserverTable const* const&, bool, unsigned int, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&)
    mozilla::image::ProgressTracker::SyncNotifyProgress(unsigned int, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&)
    mozilla::image::RasterImage::NotifyProgress(unsigned int, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::Maybe<unsigned int> const&, mozilla::image::DecoderFlags, mozilla::image::SurfaceFlags)
    mozilla::image::RasterImage::RequestRefresh(mozilla::TimeStamp const&)
    nsRefreshDriver::Tick(long long, mozilla::TimeStamp)

I've also taken a CPU usage profile for all threads using Instruments (with "Record waiting threads" unchecked). 42% of the CPU usage is inside ff_vp8_decode_frame, and 6% inside the memcpy in MappedYCbCrChannelData::CopyInto.

So, to summarize, the CPU usage is coming from VP8 video decoding and unnecessary display list rebuildings.

Comment 2

[Andrew Osmond [:aosmond] (he/him)]

Hm it appears to be https://media.newyorker.com/clips/5a4fe6b5d2c7ce77056a3064/master/pass/180115_stillman_opener.mp4.gif which is a 1920x1080 GIF. It doesn't seem to be animating on the page though, so probably related to the work I'm considering for bug 1354913.

Comment 3

[Markus Stange [:mstange]]

(In reply to Andrew Osmond [:aosmond] from comment #2)
> Hm it appears to be
> https://media.newyorker.com/clips/5a4fe6b5d2c7ce77056a3064/master/pass/
> 180115_stillman_opener.mp4.gif

Andrew and I looked into this some more and it looks like that's not the image that's responsible - that image is inside a <video> element, so there is no image frame created for it. (The page info window's media tab uses custom code to find images by walking the DOM, and it is not aware that images within <video> elements should be skipped.)

Instead it appears to be this image: https://www.newyorker.com/images/loaders/eustace.gif
I don't see that image anywhere on the page, though.

Comment 4

[Timothy Nikkel (:tnikkel)]

(In reply to Markus Stange [:mstange] from comment #3)
> Instead it appears to be this image:
> https://www.newyorker.com/images/loaders/eustace.gif
> I don't see that image anywhere on the page, though.

That gif is used as the background on a div that contains an iframe which contains the videos that are along side the article. So they are covered by the iframe contents.

Comment 5

[Gregory Pappas [:gregp]]

Unable to reproduce on Linux using the live page or an archived version.

Can anyone still reproduce on macOS?