Open Bug 1823474 Opened 2 years ago Updated 2 years ago

Divi's intensive use of shadows on its demonstration page cause slow performance issues in Firefox on some graphics drivers

Categories

(Core :: Graphics: ImageLib, defect)

Firefox 110
defect

Tracking

()

UNCONFIRMED

People

(Reporter: nekohayo, Assigned: tnikkel)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

  1. Go to https://www.elegantthemes.com/gallery/divi/
  2. Scroll down a bit to the section that begins with the heading "2,000+ Pre-made Designs" (you can Ctrl+F for that string if you want)
  3. Hover the mouse over the various "packs" shown as trios of thumbnails with blue shadows

Note: you might need open source radeon graphics for this issue to exhibit itself most reliably (as such drivers might exacerbate existing performance problems). It is particularly visible with my Radeon R7/R9 270 on Xorg/X11 on Linux, in Fedora's GNOME session.

Actual results:

When you hover those triple-card packs thumbnails thingies with their blue shadows, they animate... but unless you're running a super fast bleeding-edge overpowered computer with the latest GPUs and super-optimized graphics drivers, you will most likely notice some non-smooth animation of those shadowy images. It will not be butter-smooth 60fps for sure, more like 3 to 12 or 20 fps on some computers.

On my ThinkPad X220 with Intel Sandybridge graphics on X11 it animates at something that looks like ~20 fps (just a guess), whereas on my Radeon R9 270 on X11 it barely manages a handful of frames per second, or just skips the animation and goes from start to finished state because it can't do it smoothly.

Expected results:

Smooth (60fps+) animations at all time, everywhere, with any elements on that page.

Chrome is pretty much the only other browser that I tested that handles this smoothly, on the same hardware; in Chromium, the animations for those "website packs" thumbnails with shadows are smooth.

While one could blame the website for using too much eyecandy, I think it would be best to use this as a standard benchmark to improve Firefox and bring it to Chrome's performance levels in this specific area. Divi is an extremely popular WordPress site builder theme, and since WordPress represents 40-50%+ of public websites out there, this is kind of a big deal.

Improving performance here might also help with performance within the Divi website builder editor itself, and on other themes/tools that use similar graphics pathways.

Not entirely sure how to classify what's gong on here from the profile as it shows a lot of strange activity, both in display list building and also image decoding. Maybe Glenn or Timothy might have a better idea...

Severity: -- → S3
Flags: needinfo?(gwatson)

Ah, thanks for the heads up. I think this is a similar problem as bug 1786918. The image size is being animated and we try to decode many different sized versions of the same image, which wouldn't be too bad except we also are doing some (all?) of those decodes sync. We should just paint with the slightly different size already decoded image instead of sync decoding one a few pixels smaller/bigger.

Blocks: 1801052
Flags: needinfo?(gwatson)
Severity: S3 → S2
Component: Graphics: WebRender → Graphics: ImageLib
No longer blocks: gfx-triage
Assignee: nobody → tnikkel

In case this is somehow useful, although the engine is certainly completely different: while Chromium is unaffected, WebKitGTK is, so there's I filed a corresponding bug report with sysprof measurements in https://bugs.webkit.org/show_bug.cgi?id=256105

You need to log in before you can comment on or make changes to this bug.