Australis Performance Post-mortem Part 4: On Tab Animation | Hacker News Reader

Australis Performance Post-mortem Part 4: On Tab Animation

mikeconley.ca

36 pointskhc16 comments

I don't know...if Mozilla is still having problem with tab animations by now, why not just scrap it all together until their multi-process gain some ground.

All this fancy animations they've added into Australis are non-essentials and impacting their already super busy single threaded model.

I've had issues with Chromes tab animations in the past. Particularly when dragging a tab from one window to another I've been left with a hole that didn't close up. Invisible tab syndrome. This blog post demonstrates Mozilla are putting in some decent QA, so I'll give them the benefit of the doubt.

Being not a fan of UI animation myself, I agree completely. The fastest way to open/close a tab is to not animate it at all. To me, it's rather odd to see concern about a ~5ms difference in animation speed, when they could've made the whole animation take 0ms quite easily --- the faster an animation goes, the more instantaneous and less animation-like it becomes, and when it gets fast enough, there's no point in having any animation.

I wonder if removing all the user-initiated animation from the UI would improve perceived responsiveness dramatically, since my browser has no tab animation and a new tab appears instantaneously as far as I can tell.

That said, it's amazing in a somewhat shocking sort of way to see just how many layers of abstraction and lines of code are involved in doing something like a tab animation (I notice the article mentions CSS, Direct3D, Cairo, SVG, and OpenGL), and then realise that in terms of human timescale, it's still extremely fast.

I'd like to see the video with the side/by-side demonstration of "no animation" vs "animation" of the tabs, synchronized to the moment of the click.

One of the first things I do after installing firefox, in the about:config page, is setting 'browser.tabs.animate' to false.

Yes it's hard to imagine how much energy is spent on just implementing the "when I click the new tab, that new tab must slowly and not immediately appear" (there's even the whole terminology TART/CART https://wiki.mozilla.org/Buildbot/Talos/Tests#TART.2FCART (thanks Wilya)). I hope there's some higher goal behind.

I'm also curious to know how much of the problems still come from "not nativeness" of the UI (up to some point at least, Mozilla was proud to use some very complex architecture instead of the native controls, I don't know the current status, if I understood more OS-native always has benefits, except for not allowing easy "themes" development).

Hey, post-author here.

I would argue that they're not non-essentials. They may not be functional essentials, but they certainly add to the experience of running a polished, smooth browser.

You'll be happy to note that I've been loaned out to the Electrolysis team. We're making headway on that front for Desktop, and you can already test it on Nightly[1]. Open up a copy of Nightly, and go to File > Open new e10s window. A new window will open that has its tabs use child processes (you can tell when this is working because the tab's title will be underlined).

We hope to enable this by default on Nightly in the near future.

[1]: http://nightly.mozilla.org/

Reading the title it sounded like Australis is dead or its performance is dead ("post mortem" is Latin for "after death": post (“afterwards”) + mortem, from mors (“death”).)

Reading the article (not carefully, I admit, and using google cache, I can't get the page otherwise), I haven't figured out what the TART stands for. But tl dr seems to be "we make this Australis UX revision, and then the tabs are slow, and we see it on the fastest machines, then we search for causes, then we fix them." Well yes, that's the right thing to do. Can somebody point to something interesting in the article that I missed to recognize?

TART stands for "Tab Animation Regression Test".

And I still don't know what is actually meant under the "tab animation." That when I click on the "new tab" it slowly appears? Or something else?

Yes. It measures the time taken to open a new tab, in various configurations. [0]

[0] https://wiki.mozilla.org/Buildbot/Talos/Tests#TART.2FCART

'Software postmortem' are done after the product is shipped or failed to ship. We already know it's shipped.

For "failed to ship" I understand, but I wonder how "shipping" can be equivalent to "death"? Post mortem is always "after death" not "after birth":

http://en.wikipedia.org/wiki/Post-mortem_(disambiguation)

The project has entered maintenance mode. All development has ceased.

Yeah, I know what it means, it felt a bit weird at first (I'd go for dissection to be honest). But languages don't change based on math principles. It's from context of game/software postmortems: http://www.gamasutra.com/features/postmortem/

Queer means strange, except it doesn't, gay means happy, except it doesn't.

Well, doing UI work right now as well, it is quite interesting what bugs cause the performance regression.

Take the OS-titlebar-issue. I can really easily imagine how much time and nerves it took to find this one.

Apart from that, it is just a nice insight how they benchmarked and solved an issue. It is good to see that Mozilla is doing that properly, especially given how much Chrome kicked FFs ass in the early days.

Here's my post-mortem on Australis: I stopped using Firefox.

Reply on news.ycombinator.com