WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 3 months ago

#32597 new defect (bug)

mediaelement.js high CPU usage triggered by the buffering CSS animation

Reported by: afercia Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: External Libraries Keywords:
Focuses: Cc:

Description

Noticed by @iseulde, see discussion here:
https://wordpress.slack.com/archives/core-editor/p1433862939000659

Also reproduced on my (very old) machine that makes things very evident. Looks like mediaelement.js audio uses a linear gradient animation on the mejs-time-buffering element which triggers a Firefox bug. I remember similiar issues in Firefox reported years ago and probably never fully fixed. Should probably be reported upstream. See screenshot:

https://cldup.com/tAifYTyqQw.png

Removing that element from the DOM makes the CPU usage go down to 0.

Attachments (1)

32597.png (592.0 KB) - added by afercia 3 months ago.

Download all attachments as: .zip

Change History (10)

This ticket was mentioned in Slack in #core-editor by afercia. View the logs.


5 years ago

#2 @iseulde
5 years ago

  • Component changed from General to External Libraries

#3 @Hareesh Pillai
14 months ago

  • Keywords reporter-feedback added

Hi @iseulde and @afercia,

The mediaelement.js library has been updated to v4.2.13 in #46681
Can you please confirm if this bug still exists?

#4 @afercia
14 months ago

@hareesh-pillai just tested with latest Firefox 69 on a macBook Pro. Seems when the mejs-time-buffering element is hidden with display: none; the CPU usage is normal. So this seems to be improved, as previously the CPU usage increase was happening also with the element hidden.

As soon as the element with its animation gets visible, the CPU usage increases to ~ 20% on my machine. On less powerful hardware the increase is likely way higher. Normally, mejs-time-buffering should be visible for a few seconds or even less but I'd say it still produces an undesirable side effect.

#5 @desrosj
3 months ago

  • Keywords close added
  • Milestone set to Awaiting Review

I'm not sure how this could be improved on WordPress' side of things without a change upstream in mediaelements (perhaps a new option to disable this buffering animation). It does not seem like the animation can be disabled in the current version of the library.

@afercia is there any way to confirm that the ~20% CPU increase is being caused by the animation itself and not the fact that the window begins downloading and processing the audio file? Also, can you confirm that this does not just happen in the Classic Editor, but in the block editor and on the front-end as well?

Also, I attempted to find the Firefox issue that you referenced but did not have much success. If you are able to recall the issue, can you please share the link here?

I am going to mark this with a close recommendation with a suggestion to report-upstream unless it becomes apparent how to fix this on the WordPress side.

Noting #51315 as related, as this will update the library from 4.2.12 to the latest release, 4.2.16, though nothing in the changelog references the performance issue documented here.

#6 follow-up: @afercia
3 months ago

  • Keywords reporter-feedback close removed

@desrosj googling for "firefox bugzilla css animation cpu" returns some related bug reports on the bugzilla bug tracker.

For the records, historically Firefox had problems also with animated GIFs, see googling for firefox bugzilla animated gif cpu.

Spinner icons and animated GIFs already cause problems in the past, see for example #33322. I guess this is no different for CSS animations.

is there any way to confirm that the ~20% CPU increase is being caused by the animation itself and not the fact that the window begins downloading and processing the audio file?

Test it and hide the animated element with display: none or removing it from the DOM? :) As I wrote in the ticket description: "Removing that element from the DOM makes the CPU usage go down to 0".

Also, can you confirm that this does not just happen in the Classic Editor, but in the block editor and on the front-end as well?

If the animation is shown, I don't see why it should not happen also there.

I'm not sure how this could be improved on WordPress' side of things without a change upstream

Hiding the animated element with display: none should work. Reporting upstream and asking for a fix is also an option.

#7 in reply to: ↑ 6 @desrosj
3 months ago

  • Keywords close added

Replying to afercia:

googling for "firefox bugzilla css animation cpu" returns some related bug reports on the bugzilla bug tracker.

Thanks for the link. The wording of your report made it seem like you had a specific bug in mind.

Test it and hide the animated element with display: none or removing it from the DOM? :)

I should have clarified that I am unable to reproduce the issue locally in trunk using Firefox nightly (82.0a1 (2020-09-15)) on MacOS 10.15.x. My machine surely has more resources than the older machine you mentioned in your original report, but I did not observe any significant increase in memory usage (at most, a few MB).

My recommendation to close still stands. Helping to fix this in Firefox or requesting a less problematic loading indicator in MediaElements would have a much greater impact.

Leaving this open until someone that can reliably reproduce the issue is able to open a report upstream or follow up on an existing ticket.

Last edited 3 months ago by desrosj (previous) (diff)

#8 @afercia
3 months ago

  • Keywords close removed

Leaving this open until someone that can reliably reproduce the issue

There you go (see attached screenshot).

Tested on a MacBook Pro end 2015 (not a brand new one but still powerful enough). Notes:

  • this now happens only with posts made with Classic Editor, as the block editor uses the native <video> element thus browsers use their own players
  • worth noting that these posts will use mediaelement.js also in the front end so the high CPU usage will happen also on the front end, which is unfortunate

To reproduce:

  • use Classic Editor
  • add an audio
  • mediaelement.js will display its player
  • the easiest way to reproduce is by _not_ playing the audio and instead:
  • search in the browser's dev tools for an element with CSS class mejs-time-buffereing
  • make it visible by unchecking display: none (see screenshot)
  • the buffering CSS animation will appear
  • monitor the CPU usage with Activity Monitor (on macOS) or other tools if on Windows
  • in my case, testing with Chrome 85, the CPU usage goes up to 63%, which is crazy high

This can be a huge problem when the network is unstable and buffering kicks in or when, as mentioned in the Slack conversation linked in the ticket description, a post is left open in a browser tab for some time.

Worth also noting this ticket is 5 years old but it's still a problem for millions of posts published with previous versions of WordPress where the front end still uses mediaelement.js

@afercia
3 months ago

#9 @afercia
3 months ago

  • Summary changed from mediaelement.js high CPU usage in Firefox to mediaelement.js high CPU usage triggered by the buffering CSS animation

Lastly: it appears it's not only Firefox, as the test above was ran using Chrome. Updating the ticket title.

Last edited 3 months ago by afercia (previous) (diff)
Note: See TracTickets for help on using tickets.