Hacker News Reader

Comment by scrollaway | Hacker News Reader

Quantum has been really good performance wise on most sites. It's most flagrant on the Stripe API docs, which are sluggish as hell on Chrome Linux and butter-smooth on Firefox: https://stripe.com/docs/api

However, I have two major tab-management issues with Firefox which make it near-unusable for me:

1. No support for "scroll wheel to switch tabs" (scroll on tabs to switch between them). This is a feature common to nearly all Linux software and Firefox removed it a few versions ago. Quantum killed "Tab Wheel Scroll" which reimplemented it.

2. No support for multi-select tab management, which Chrome is amazing with. If you didn't know, in Chrome, you can ctrl+click and shift+click tabs to select multiple at once and close, move or snap all of them at once like in a file manager. Super useful.

View on HN

> sluggish as hell on Chrome Linux and butter-smooth on Firefox: https://stripe.com/docs/api

Hi; I work on scrolling/rendering in Chrome. Thanks for bringing this to my attention, that is some super janky scrolling in Chrome >_<. I've filed http://crbug.com/786991 for us to look into it.

Some technical background (since this is HN after all); at a quick glance there are two things going wrong here in Chrome.

1. We would normally want to 'composite' the scrolling region here, which means we paint the pixels only once into a saved layer and then just slide that up and down as you scroll. I believe that is not happening on the Stripe page because of the unusual way that they are doing the split-panel background. Looks like we're currently unable to tell that the background is an opaque color, so we can't apply sub-pixel font AA[0] - and on low DPI we will refuse to composite in that case.

2. Chrome's repainting of this page is really slow. :(. Firefox Nightly is also repainting the page when you scroll (as far as I can tell), but they're definitely doing it much faster than Chrome!

So our goal will be to try and figure out how to composite this page, and if that's not possible then we'll have to dig into the slow painting.

Note: Because we composite more readily on high DPI devices (where sub-pixel font AA[0] doesn't matter), this site should scroll nice and fast on a high resolution display. This includes most new laptops, all (?) phones/tablets, etc.

[0]: https://en.wikipedia.org/wiki/Subpixel_rendering

Omg a Chrome developer using the word “subpixel aliasing” in real life! I have been looking for you!

I’m about to go mad because I’ve been reporting bugs in subpixel aliasing under hi-dpi displays with non-standard DPIs (!= 96dpi) for a while but the Chromium QA team in India has been having a hard time triaging them, possibly because of the hi-dpi display requirement.

I’ve also got a fully reproducible issue involving CSS transforms I haven’t bugged yet as I’ve just been struggling to get someone to triage #765848 correctly as of yet:

https://bugs.chromium.org/p/chromium/issues/detail?id=765848

Can you send me an email, pretty please? mqudsi [at] NeoSmart [dot] net

I was experiencing this particular bug on all my hi-dpi machines but it magically went away on one of them (perhaps after an OS update, as it’s running Windows 10 RS4 seeds) but it’s fully reproducible on all my other machines with a clean profile on all channels.

Thanks a lot for the insight! Really cool to see a reply straight from the horse's mouth :)

> Note: Because we composite more readily on high DPI devices (where sub-pixel font AA[0] doesn't matter), this site should scroll nice and fast on a high resolution display. This includes most new laptops, all (?) phones/tablets, etc.

Not the case for me. Touchscreen display on a UX asus laptop, 3.2k resolution on linux with intel card. Scrolling using the touchscreen is snappy, scrolling using the scroll wheel (synaptics emulation) is even worse than on my desktop.

I think it depends on what your DPI is set to. The resolution itself doesn’t necessarily mean much, but typically 3k+ resolutions are accompanied with > 96dpi configurations.

> sluggish as hell on Chrome Linux and butter-smooth on Firefox: https://stripe.com/docs/api

Wow you were not exaggerating on that.

Firefox used to have the amazing "Mouse Gestures Suite" add-on, which provides scroll-wheel-in-tabs and rocker navigation. Unfortunately with the new Firefox (since v57) it doesn't work anymore, since it uses the old extension approach.

There seems to be a new add-on for the web extension approach (https://addons.mozilla.org/en-US/firefox/addon/foxy-gestures...), but I haven't tested it yet and am not sure how robust it is at this point.

AFAIK there is currently no extension that would support rocker gestures.

Also mouse gestures now have the same annoying "feature" they've always had in Chrome: they don't work in "system" tabs (think about:preferences).

So you can't use mouse gesture to quickly go through opened tabs if at least one of them is the "system" one, the navigation simply dies there.

I've tried out the Foxy Gestures add-on in the meantime. It turns out it has rocker gestures (called 'chord gestures' in the 'Other Gestures' setup tab) and besides the drawback you mentioned (doesn't work in system tabs) it works well so far.

That's great news, thank you.

I don't think they're ever going to fix the "system tabs" issue, since it's supposedly a "feature", but at least some good news. :)

There was a custom xpi of mouse gestures redox that has a few more updates, but it's sadly unmaintained and broken in 57.

I've yet to find a gesture extension that supports the same rocker gestures (i.e. middle click + other click to change tabs).

If scroll wheel switches tabs, what happens when you have enough tabs that they don't fit in the tabbar and the tabbar becomes scrollable? Does scrolling still switch tabs, or does it scroll the tabbar so you can find the tab you want to switch to? I believe in Firefox it does the latter. Chrome never has a scrollable tabbar (which has its own UX issues with lots of tabs), so doesn't have this problem...

Looks like https://bugzilla.mozilla.org/show_bug.cgi?id=566510 tracks the multiselect thing in Firefox and has seen some recent movement... That would indeed be very nice to have!

You want the Multiple Tab Handler add-on for Firefox. It's 57 ready and even works with tree style tabs.

> 2. No support for multi-select tab management, which Chrome is amazing with

Yeah I am missing this as well. I switched to Firefox a few days ago after hearing about all the improvements.

So far, three issues:

1- On my MBP, I am having serious issues when I have tabs to recover.

2- HTML5 videos are not hardware accelerated. Neither on OSX, nor on my Arch.

3- Cannot move multiple tabs from one window to another but that actually seems to work better with i3's drag and drop.

About acceleration - dunno about macOS, but on GNU/Linux there's lots of low-hanging fruits to get by tweaking a few entries in about:config. Check out https://wiki.archlinux.org/index.php/Firefox/Tweaks

Thank you for the multi-tab tip! I can't tell you how many times I've wrangled with Chrome to move more than one tab into a separate window while my tiling window manager fights to split each tab into a window separately.

The Stripe docs work great on Mac Chrome, interesting that Linux fails there.

They also jank on windows - but only on my 1080p display. When I move it along to my 4k display, it suddenly janks a lot less, about 50fps or so. I wonder why chrome is turning on composition in 4k and off in 1080p?

Regarding #2, try All Tabs Helper. From your description it might be acceptable solution. Found it a few months ago and has become invaluable to me.

I’ve been using Chrome since the very first release, and yet never knew about your point #2. Thank you for sharing!

Reply on news.ycombinator.com