User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce: 1. On macOS, Open Activity Monitor (Open Launchpad and type 'Activity Monitor' on the top search bar) 2. Run Firefox without any addon (or safe mode) 3. Go to http://mentalfloss.com/article/504666/bit-bit-inside-rise-retro-gaming 4. After the web page finished loading, enter Reader View 5. Look at the Activity Monitor and wait until the CPU load is stable (My PC: Idle 95%) 6. After the Reader View finished loading, press the read button of the left and then press the play button Actual results: After the play button is being pressed, the CPU load will jump from 95% Idle to 75% Idle, I guess it means the computer consumes 20% CPU to read the article. On my PC, that 20% is the reason why my CPU fan starts running and my laptop is getting hot. Expected results: Please repeat the same test on Safari, after open the page on Safari please choose 'Edit'→'Speech'→'Start Speaking'. Then go back to Activity Monitor and read the CPU reading. On my side the CPU jump from 95% idle to 92% idle. In Safari the TTS would trigger only 3-5% CPU load. As both are using mac built-in TTS engine I would expect the CPU load would be similar.

I am not sure but this counter example, this one work flawlessly. 1. Open Activity Monitor 2. Open Firefox and then go to https://codepen.io/anon/pen/RLLgGE 3. At the bottom of the page, paste the following piece of article the textbox 'Nintendo swears it’s ready to fill orders for the Super Nintendo (SNES) Classic hitting stores at the end of this month. If so, it’s likely that a game console released more than a quarter-century ago could become one of the hottest gifts of the 2017 holiday season. It’ll join a series of retro releases intended to evoke memories of the Sega Genesis, classic games like Street Fighter II, and even original titles meant to replicate the euphoria of digging into a brand-new NES game on the drive home from Toys "R" Us.' 4. Then press the play button 5. Watch the CPU consumption in activity monitor You will see that this demo consume 3-5% of CPU power. But in this example I find another issue in Firefox. 1. Open Firefox and then go to https://codepen.io/anon/pen/RLLgGE 2. At the bottom of the page, paste the following piece of article the textbox 'This is a test' 3. Then press the play button After the textbox message is read completely, pressing the speak button WILL NOT re-read the textbox message. I have to refresh the page in order to read the article again. Please try this test case in Chrome and Safari. Both browser can re-read the textbox message.

Just tried that the latter case problem (Web Speech API restart problem) no longer exist on Firefox 58.0a1 (10-26) Nightly. The main reason I tried Firefox Nightly is because the Reader Mode TTS bug (bug 1406358) is fixed. So I tested both cased on the Nightly version. Still, the Reader Mode TTS would cause much more CPU power than Web Speech API. To avoid my mac getting too hot, now the best way is to 1. Open the Web Page in Reader Mode 2. Open a tab that uses the Web Speech API (e.g.https://codepen.io/anon/pen/RLLgGE) 3. Copy the text from (1) to (2) 4. Play the audio on (2) (In reply to Winston from comment #1) > I am not sure but this counter example, this one work flawlessly. > > 1. Open Activity Monitor > 2. Open Firefox and then go to https://codepen.io/anon/pen/RLLgGE > 3. At the bottom of the page, paste the following piece of article the > textbox > 'Nintendo swears it’s ready to fill orders for the Super Nintendo (SNES) > Classic hitting stores at the end of this month. If so, it’s likely that a > game console released more than a quarter-century ago could become one of > the hottest gifts of the 2017 holiday season. It’ll join a series of retro > releases intended to evoke memories of the Sega Genesis, classic games like > Street Fighter II, and even original titles meant to replicate the euphoria > of digging into a brand-new NES game on the drive home from Toys "R" Us.' > 4. Then press the play button > 5. Watch the CPU consumption in activity monitor > > You will see that this demo consume 3-5% of CPU power. > > But in this example I find another issue in Firefox. > 1. Open Firefox and then go to https://codepen.io/anon/pen/RLLgGE > 2. At the bottom of the page, paste the following piece of article the > textbox > 'This is a test' > 3. Then press the play button > > After the textbox message is read completely, pressing the speak button WILL > NOT re-read the textbox message. I have to refresh the page in order to read > the article again. Please try this test case in Chrome and Safari. Both > browser can re-read the textbox message.

Based on Makoto's findings, the root cause of the high CPU load is the painting within the Reader Mode (bug 1406358 comment 25).

So I guess this is a result of the word/paragraph highlighting and the animations. Milan, how do we go about isolating what specifically is causing the excess CPU use here? I wouldn't really expect the effects to be as drastic as they are here...

Bug 1406358 comment 25 says "Narreta will update content for maker every time" so that may be a place to start. Otherwise, capturing a profile is probably a good first step.

(In reply to Milan Sreckovic [:milan] from comment #5) > Bug 1406358 comment 25 says "Narreta will update content for maker every > time" so that may be a place to start. So, we run JS when narrate notifies word boundaries are reached, which then animates some CSS stuff. The transitions are here: https://dxr.mozilla.org/mozilla-central/source/toolkit/themes/shared/narrate.css?q=path%3Anarrate.css&redirect_type=single#18 the JS that calls these is here: https://dxr.mozilla.org/mozilla-central/source/toolkit/components/narrate/Narrator.jsm#319 I'm not entirely sure what would be the best way of improving this code. I'm not sure we can do all that much caching or relying on lazy bounds instead of getBoundingClientRect because we smooth scroll the document to pull things into view, while we're narrating... I'm also not sure if using a transform instead of rel/abs positioning would improve performance here or not, or if there are other, more obvious things to try. Maybe Eitan has ideas? > Otherwise, capturing a profile is > probably a good first step. There's a profile in the comment you mentioned, but the significant factor here seems to be a bunch of layers/painting code so I'm struggling to go from that to actionable things to do in the frontend (CSS/JS changes). See https://perfht.ml/2za9YWK for a zoomed-in look on what seems to be CPU-intensive here (in short bursts, on every frame or so).

I need to check this out on a mac to see what we can do. Does this issue appear in Windows? I don't see why it wouldn't. Aside from Gijs's suggestions, if the animated transitions are having a performance impact, I would just give up on them.

Keeping myself needinfo'd to remember to test this on a mac.

This doesn't seem to be an issue in Windows..

Hi developers, After I done this the reader mode CPU loading is back to normal. Please use FF57 if you are running macOS 10.13+. 1. Open Article in Reader View (Like Comment #1) 2. In Reader View, inspect the Narrate Button (On the Left toolbar, right click the third button, then choose 'Inspect Element'). In the 'Inspector', you should now be highlighted on the 'button' element. 3. Go to all the way to 'button' → 'svg' → 'style' & 'g'. Delete the 'g' node (Right click 'g' node and select 'Delete Node'). Now the narrate icon is gone but it is still working. 4. Click on the dissapeared narrate button and then select play and listen to the TTS I hope this helps the debugging process.

As removing the 'g' element improves the performance. Commenting out '.narrate-word-highlight' in 'narrate.css' also improves the CPU load. When the 'g' element is being removed, the fan of my MacBook Pro don't run anymore. The CPU loading drops from 50% idle to 80% idle. When I comment out the '.narrate-word-highlight', the CPU loading goes from 80% idle to 92% idle.

I extracted the narrate waveform animation on Codepen (https://codepen.io/anon/pen/KyqbgK) and tried to run the narrate animation on different browsers (chrome, firefox, safari) on macOS. Seems all browsers are using 20-30% CPU load animating the narrate waveform.

Thanks Winston, that is super interesting. Brian, are we doing something wrong here? Are CSS animations just a bad idea?

Just looking at the codepen from comment 12 I only see 2~3% CPU usage on Windows. The content itself looks fine (everything appears to be running on the compositor) and when I profile it I don't see anything unusual showing up (just a bit of work on the compositor, as one would expect). CSS animations are a fine idea -- they're generally going to be much more performant than, say JS animation, and especially if you're animating transform/opacity. Regarding the original report in comment 0, I still only see ~5% on Windows when reading that article. The CSS transitions could be converted to using transform -- that should help avoid some unnecessary layout and painting. Other than that, I guess it's possible that we're hitting some sort of slow path when applying transforms to SVG content on Mac but someone on the graphics team would know much better than I.

Yes I could confirm that the CPU load on windows is reasonable and snappy. Instead my worries would be the CSS performance of Firefox on macOS, especially when it is running on animation mode. I was reading some benchmark about Firefox (on Windows & macOS) and compare the benchmark between Firefox to Chrome. I am using Chrome as a reference and will use Motionmark as a reference. The reason why I mention Motionmark is because it involves not only calculation but also drawing. https://www.phoronix.com/scan.php?page=article&item=firefox-quantum-bench&num=3 This benchmark shows that the Motionmark on Windows Firefox 57 Beta: 173 Chrome 60: 329 (1.90x) http://www.01net.com/actualites/macos-high-sierra-notre-test-que-vaut-le-nouveau-safari-face-a-chrome-et-firefox-1267443.html This benchmark shows that the Motionmark on macOS Firefox 57 Beta: 61 Chrome 61: 285 (4.67x) Since the benchmarks are done on different devices so I rather focus on the ratios of benchmark on Chrome and Firefox. I don't think this benchmark can reflect the real situation but it is worth taking a look. Also I wonder if it is possible to have some short term solution on the macOS? Thanks

I'm curious if this issue will go away once bug 1419079 lands.

Eitan, I am not sure but as the report said Firefox 52 don't have issues, I have done the following test: 1) Downloaded Firefox 52.5.0 ESR on my mac (running 10.13) 2) Go to https://codepen.io/winstonma/full/vWdYxP/ 3) Open Activity Monitor and monitor the CPU loading 4) Repeat the following with Firefox 57 Here are the result: Firefox 57: 15-20% CPU Load Firefox 52: 30-35% CPU Load In FF 52 & 57 the load drops to 3% once the animation element (grow keyframe in CSS) is being removed. This seems So I guess the reader mode animation problem can't be solved by downgrading to Firefox 52. But at the same time I am not sure if the patch will solve the problem. I could help rerun the test once the patch is release on Firefox alpha.

Sorry, just checked that I am not running Firefox 57, it is Firefox 58b4. I recorded a profile https://perfht.ml/2k6bgi0 on Firefox 58b6, using the test procedures on comment 17.

The reader mode waveform in FF60 no longer move. Is it the desired feature? If it is, then this issue is no longer valid. But I am still interested on why the CSS animation performance on FF is not good.

I'm not sure the issue is related to CSS animation. There have been other similar reports that are Mac-specific and so this seems more likely to be a Mac-specific graphics issue.

Brian, I agree that there is no CSS animation issue on Windows. I agree this is a Mac-specific issue. However I believe my test case on comment 17 is still valid and even on FF60 the CPU load is high. But as the narrate animation is no longer exist, I guess this ticket is no longer valid. Either rename the ticket or close this ticket (and open another new ticket) would be a plausible solution.

Right, I'm just suggesting it's a graphics issue, not an animation one. As best I can tell, bug 1407536 is the same issue. Duping to that bug.

(In reply to Winston from comment #19) > The reader mode waveform in FF60 no longer move. Is it the desired feature? No, the waveform is unrelated to the animation. The waveform not moving is a result of bug 1447384, the fix for which I decided not to uplift to 60 because it wasn't entirely trivial and the impact seemed so minor that it wasn't worth it late in the cycle ( https://bugzilla.mozilla.org/show_bug.cgi?id=1447384#c2 ). So 60 has a stationary waveform - but the rest of the animations (for narrate) are still happening, AIUI. If the graphics team is tracking that in bug 1407536 that wfm.