4 ms·

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. Al

by ethana 12y ago

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.

nly 12y ago
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.
userbinator 12y ago
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.
- acqq 12y ago
  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.
Luyt 12y ago
One of the first things I do after installing firefox, in the about:config page, is setting 'browser.tabs.animate' to false.
acqq 12y ago
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 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).
mconley 12y ago
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/ http://nightly.mozilla.org/

by ethana 12y ago

nly 12y ago

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.

userbinator 12y ago

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.

acqq 12y ago
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.

Luyt 12y ago

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

acqq 12y ago

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 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).

mconley 12y ago

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/ http://nightly.mozilla.org/