1943857 - Testcase that generates 10k 1x1 pngs/AVIFs, spends 8 seconds in "Layout Cleanup" on reload. Time increases superlinearly with number of pngs.

Status: NEW

(Core :: Graphics: ImageLib, defect)

Description

[Mayank Bansal]

Attachment: PNG_URI.HTML

Open the attached testcase
Enter 10000. Click generate
Now open a new tab in foreground and put this tab in the background
Reload the backgroudn tab (with the testcase)

Nightly: https://share.firefox.dev/3WANev4 (7.3 seconds)
The time increases superlinearly.

Comment 1

[Daniel Holbert [:dholbert] (PTO until 2/24)]

~all of the cleanup time is with this backtrace:

mozilla::image::ImageObserverNotifier<const mozilla::image::ObserverTable *>::operator()(mozilla::image::ProgressTracker::OnDiscard::<lambda_7>::operator()::<lambda_1>) [image/ProgressTracker.cpp]
mozilla::image::ProgressTracker::OnDiscard::<lambda_7>::operator()(mozilla::image::ObserverTable const*) const [image/ProgressTracker.cpp]
mozilla::image::CopyOnWrite<mozilla::image::ObserverTable>::Read(mozilla::image::ProgressTracker::OnDiscard::<lambda_7>) const [image/CopyOnWrite.h]
mozilla::image::ProgressTracker::OnDiscard() [image/ProgressTracker.cpp]
mozilla::image::RasterImage::Discard() [image/RasterImage.cpp]
mozilla::image::RasterImage::RequestDiscard() [image/RasterImage.cpp]
imgRequestProxy::RequestDiscard() [image/imgRequestProxy.cpp]
nsImageLoadingContent::UntrackImage(imgIRequest*, mozilla::Maybe<mozilla::OnNonvisible> const&) [dom/base/nsImageLoadingContent.cpp]
nsImageLoadingContent::OnVisibilityChange(mozilla::Visibility, mozilla::Maybe<mozilla::OnNonvisible> const&) [dom/base/nsImageLoadingContent.cpp]
nsImageFrame::OnVisibilityChange(mozilla::Visibility, mozilla::Maybe<mozilla::OnNonvisible> const&) [layout/generic/nsImageFrame.cpp]
nsIFrame::DecApproximateVisibleCount(mozilla::Maybe<mozilla::OnNonvisible> const&) [layout/generic/nsIFrame.cpp]
mozilla::PresShell::DecApproximateVisibleCount(nsTBaseHashSet<nsPtrHashKey<nsIFrame> >&, mozilla::Maybe<mozilla::OnNonvisible> const&) [layout/base/PresShell.cpp]
mozilla::PresShell::ClearApproximatelyVisibleFramesList(mozilla::Maybe<mozilla::OnNonvisible> const&) [layout/base/PresShell.cpp]
mozilla::PresShell::Destroy() [layout/base/PresShell.cpp]

Given the observation about time increasing super-linearly, plus the fact that this is 5000 copies of the same "broken-image" graphic, I would bet this is some O(n^2) or O(n log n) behavior that comes out of incrementally clearing a list of usages of that single graphic. Maybe each removal is triggering a notification to be sent to all remaining instances of the image, or something like that?

--> Moving to imagelib.

Comment 2

[Daniel Holbert [:dholbert] (PTO until 2/24)]

(In reply to Daniel Holbert [:dholbert] from comment #1)

Maybe each removal is triggering a notification to be sent to all remaining instances of the image, or something like that?

Hmm, the documentation for Discard does suggest that all calls after the first are supposedly no-ops in this case:
https://searchfox.org/mozilla-central/rev/a965e3c683ecc035dee1de72bd33a8d91b1203ed/image/imgIContainer.idl#571-575

/**
 * If this image is unlocked, discard its decoded data.  If the image is
 * locked or has already been discarded, do nothing.
 */
void requestDiscard();

So: given how much time the profile is spending in Discard: either we're failing to make those subsequent calls be actually no-ops, or we're doing that part properly and it's just that the one substantial call that we do honor (the first Discard call) takes forever for some reason.

Comment 4

[Mayank Bansal]

Attachment: AVIF.HTML

https://share.firefox.dev/4gmTQUY

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit BugBot documentation.