Hacker News Reader

Comment by pitaj | Hacker News Reader

One thing I've noticed about Firefox, especially on mobile, is that transform animations are pretty janky.

Does anyone know if this is being worked on? Should I submit a bug report?

Feel free to file a bug report with your hardware, Firefox version, and test case, yes. These often boil down to simple bugs (hardware-specific or page-specific) that can be quickly fixed when isolated.

The medium-term effort to revamp the graphics stack is WebRender. Note that, like Stylo, WebRender is not just meant to achieve parity with other browsers. It's a different architecture entirely that is more similar to what games do than what current browsers do.

Firefox’ CSS transform/animation performance is terrible on macOS. I filed a bugreport but there’s no interest in solving it unfortunately.

https://bugzilla.mozilla.org/show_bug.cgi?id=1407536

Those are very general conclusions to draw from one test case. The bouncing ball test runs at 60 FPS for me on macOS; most of the time is spent in painting, as expected. Likewise, Stripe scrolls at 60 FPS for me.

I should note that the bouncing ball test is the kind of thing that WebRender is designed to improve—painting-intensive animations—so it's obviously untrue that there's no interest in improving this sort of workload. When running your bouncing ball test in Servo with master WebRender, I observed CPU usage of no higher than 15% (as well as 60 FPS)…

> With the page at stripe.com, I don't see any difference between FF52ESR, FF56.0.2, FF57.0b14 with servo enabled, or with it disabled. On my 2012 Macbook Air with macOS 10.12, I see about 98-108% CPU on each, according to iStat Menus CPU meter. With Safari it's about 35%. That's exactly what I would expect based on past experience.

> I would probably close this as invalid, as it's not something new or specific to Quantum or Servo, or as a duplicate of one of the older bugs, though I'm not sure which.

That likely points as to why there's little movement on this bug. It's title can be interpreted to indicate a Quantum regression, but it's a general issue that's longstanding, so it may be the people that are seeing it are not focused on it (they're likely tracking down and fixing actual regressions, not known problems).

I know that doesn't help your issue, but it may help you locate the relevant bug report and lend your weight there, if you feel so inclined.

Kind of OT, but I've noticed both latency and battery-life hits for compositing WMs in X (compared to traditional WMs).

Are those things being measured at all in FF? It may be that the tradeoff is worth it (and I have no doubt it can be done better than the median compositing WM on linux), but it would be good to have that data.

On the other hand, it may be moot if Wayland does end up taking over from X.

(Nitpick: Traditional WMs composite as well, they just do it on the CPU instead of the GPU.)

That's interesting. I remember the developer of KWin (KDE's window manager) saying that he considered disabling GPU compositing when the battery runs low, but he couldn't prove that this actually saves energy. In fact, on some configurations, GPU compositing was less power-intensive than CPU compositing.

I thought traditional WMs had the clients send the draw commands directly to the server, rather than doing any compositing themselves?

It's definitely true that different GPUs have different power profiles (and even the same GPU with different drivers).

Don't forget "race to sleep". If the GPU takes 3x more power but completes 10x faster and can go back into low power mode sooner that could be another power savings.

No Qt or GTK application sends draw commands to the X server anymore (except for the final "draw window-sized pixmap"). That only applies to xterm or maybe Tcl/Tk stuff.

This still isn't compositing. If I have 10 windows all with the same X/Y coordinates, the only window sending any draw commands at all is the top window with a traditional wm.

I am still a little sceptical of WebRender. Not for its theory or implementation, but relying on Graphics Drivers and GPU to do the work continue to be a pain. There are lots of Laptop with Graphics Drivers that doesn't ever get updated.

WebRender doesn't actually necessitate a GPU backend. You could have a CPU backend just as well.

(In fact, I might up being the one writing it.) ;)

>WebRender doesn't actually necessitate a GPU backend.

Wow to me this is big news! I have long wanted the GFX part to be CPU backend instead of the trend of Hardware Acceleration on GPU.

Cant wait to see the results.

Stylo is now enabled in Firefox for Android's Nightly builds. You can install Nightly from the Google Play Store to see if Stylo makes a difference for the animation problems.

https://play.google.com/store/apps/details?id=org.mozilla.fe...

since when? I've been running Nightly for months.

Landed ~5 days ago:

https://hg.mozilla.org/mozilla-central/rev/db56323cd08f

According to this tweet, four hours ago: https://twitter.com/cpeterso/status/935594491339161600

There are no known issues about this. You should submit a bug report.

This blog has a good example of the jank you are reporting. I am observing noticeable jank on the "slideup" animation on #fixedcontent.firstvisit vs. Chrome (62.0.3202.94). (macOS/10.12.6 FF/57.0 late-2013 MBP)

In about:config, make sure privacy.resistFingerprinting is false. This messes with timer accuracy.

Reply on news.ycombinator.com