+++ This bug was initially created as a clone of Bug #1560520 +++

Affected versions
Nightly 72
Beta 71
Release 70

Affected platforms
Windows 10 - Intel/AMD/Nvidia graphics card - Webrender ON

Steps to reproduce

• Launch Firefox
• Go to https://codepen.io/MSEdgeDev/pen/mxeOGW
• Scroll down and check out the animation

Expected result
The text animation should be smooth as on Firefox with webrender disabled

Actual Result
Text animation is choppy, not as smooth with webrender enabled, check the attached recording.

Regression Range
Interestingly, this seems to happen since WebRender got enabled on my graphics card (Intel), got the pushlog that points directly to Bug 1525128.
Bug 1560520 reported before and fixed did not reveal this issue too at the time being. Back then, only that specific test string animation was choppy, not all of them.

Might be video card driver updates (for all video card manufacturers?), but this doesn't seem to be a regression of any landed patch.

So to confirm: this never worked well, is not a regression and affects all windows machines with WebRender turned on?

We can reproduce this on 3 desktop systems (Windows 10) with Intel integrated graphics (2 of them have blacklisted cards and had to be force enabled) and 3 other systems with:

• AMD RX550 (windows 10)
• Nvidia GT 1030 (windows 10)
• Laptop with Nvidia graphics (windows 10)

Could not reproduce on:

• NVIDIA GeForce GTX 970

It does not look to be a regression, given the mozzregresion pushlog revealed the webrender enabling bug (for Intel) so I can't point out to anything else atm.
However, I don't believe it was like this from the beginning. We would've noticed while reporting Bug 1560520 or at least when we verified the fix. Something changed in the meantime...

Bugbug thinks this bug is a regression, but please revert this change in case of error.

(In reply to Timea Cernea [:tbabos] from comment #2)

It does not look to be a regression, given the mozzregresion pushlog revealed the webrender enabling bug (for Intel) so I can't point out to anything else atm.
However, I don't believe it was like this from the beginning. We would've noticed while reporting Bug 1560520 or at least when we verified the fix. Something changed in the meantime...

It would be very helpful to understand what changed. Can you reverify the fix for bug 1560520 on the version that you originally verified it on and check if that version shows this bug?

So here is a recording of the latest Nightly and the one where the fix got verified: https://streamable.com/yvsu9
On the build that got verified there was a slight choppiness, but in today's Nightly you can even see a slight graphical glitch when the more sluggish animation is happening.

Trying to find a regression range focusing on that to get something helpful out of it. Sorry about the hasle Jeff. Leaving NI? on me for this.

Ok, had to bleach my eyes a couple of times to differentiate broken and better animation, here is the pushlog:
9:24.73 INFO: Last good revision: a8b8823a6b72114f4150fbcd2ab0728b833b6a04
9:24.73 INFO: First bad revision: ef5f9e04f04b648bdee5517bcbf71895acf2314e
9:24.73 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a8b8823a6b72114f4150fbcd2ab0728b833b6a04&tochange=ef5f9e04f04b648bdee5517bcbf71895acf2314e

Bug that regressed this: Bug 1574493, marking it as regression.
Note: regression range found with Intel graphics card

Really hope this can help you! :)

We have shipped our last beta for 71, so this is wontfix for 71.

Now that bug 1555376 has landed, I am reinvestigating this. It does not appear to have been solved by it although I did not expect it to.

Marking fix-optional so that this doesn't keep coming up in regression triage.

The glyphs no longer wiggle after bug 1604241 landed, but they still shimmer as the animation progresses.

Similar to bug 1605642, there is still some minor residual effects from the animation, but I believe at this point, we have to live with it. It has definitely improved significantly with the landing of bug 1605642