Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#35296 closed defect (bug) (fixed)

Image editor spinner and high CPU usage

Reported by: afercia Owned by: afercia
Milestone: 4.5 Priority: normal
Severity: normal Version: 4.4
Component: Media Keywords: has-patch
Focuses: ui Cc:


Similar to other spinner performance-related issues, see #31196, #33311, #33322, and #34951.

In the image editor (both in the Media Library and in the Media Modal), when performing an action a semi-transparent layer appears with a spinner set as background.

While on powerful machines with a modern CPU and a dedicated GPU there's just a barely noticeable CPU usage increment, on older machines the spinner set on a so large area, especially when this area is semi-transparent, can make the CPU usage grow significantly and also get stuck at 100%.

Tested on a very old desktop PC with Windows XP and Firefox 43, the time required for a single image "flip" decreases from minutes to about 2 seconds when removing the spinner.

As a best practice, spinners used as backgrounds should always be set on the smallest possible area. In this specific case there's no need to completely remove the spinner when the action completes because it's already in a <div> that gets hidden with display: none.

See in the screenshot below: before the patch the whole image editor area gets continuously re-painted while after the patch it happens only on the 20x20 pixels spinner area.



Attachments (1)

35296.patch (2.0 KB) - added by afercia 5 years ago.

Download all attachments as: .zip

Change History (3)

5 years ago

#1 @afercia
5 years ago

  • Keywords has-patch added

The proposed patch removes also the semi-transparent layer height calculation made with JavaScript. As far as I see it can be set using just CSS.

#2 @afercia
5 years ago

  • Owner set to afercia
  • Resolution set to fixed
  • Status changed from new to closed

In 36162:

Media: set the image editor spinner on the smallest possible area.

When using spinners as background images, the re-painted area should be the smallest
possible one. See similar performance issue in #31196, #33311, #33322, and #34951.

Fixes #35296.

Note: See TracTickets for help on using tickets.