60fps scrolling using pointer-events: none | Hacker News Reader

60fps scrolling using pointer-events: none

thecssninja.com

104 pointsyashness32 comments

I'm a bit surprised browsers do in-scrolling events: browser performance has been under heavy optimization for years and switching to "panning mode" with no events emitted while scrolling would seem like a splendid candidate for something like a "Turbo mode". Alternatively the change to disable events could've plausibly been written as a fix to usability bugs caused by in-scroll hover events.

This is because I'm not sure if, since -94 or so, I've seen a single case where event handling while scrolling would have actually added to browsing usability at all. It consistently creates two kinds of problems: first laggy scrolling as elements with heavy events handlers get focused and unfocused and secondly crazy behaviour when on-hover menus will open abruptly while scrolling and the state of the page ends up messed up when the scrolling stops.

It makes sense to scroll like it happens in mobile devices: the input events drive the scrolling only and the page just pans around as long as the fingers move on the screen, and the browser effectively returns to interactive mode when the scrolling stops.

Hmm. I can only see a minor performance increase in Chrome. Safari is dead smooth regardless of the option selected, and Firefox is pretty hanky even with events disabled.

This is probably a useful technique for specific situations where scroll events are causing issues, but it's definitely something that should generally be handled by the browser, rather than the developer. Still, Safari's awesome performance suggests that there's room for improvement in browsers' handling of this situation.

Considering I was just googling about, wondering why I had such awful scrolling FPS, seeing this prompted me to just make a userscript [1]. Just load it up in greasemonkey. Tested in FF2x.

Works on all pages, just adds the pointer-hover: none to the body element. Using modified code from the article. Quite useful, really. I'm surprised at how often I subconsciously guide my cursor away from content while scrolling pages to prevent hover effects popping off.

[1] http://userscripts.org/scripts/show/185715

I've noticed Safari delaying hover events while scrolling, presumably for this same reason. It seems like something the browser should handle. Individual sites shouldn't be forced to hack around the issue.

I disagree -- some apps are better when hover effects appear instantly, even in response to scrolling.

Yeah I didn't see any slowdown in Safari 10.9.

Perhaps this is a dumb question because I don't know much about browser performance optimization, but why is a modern browser unable to animate one hover effect over the currently pointed to box at 60 fps as you scroll down the page? That does not sound particularly computationally intensive.

You would have to do hit-testing on every frame (which probably involves the DOM and looking at each element's hit region), determining which CSS rules with hover this matches and apply the style. Besides, such a large glow/shadow takes some time to compute and draw (last I checked this wasn't done on the GPU – in the linked testcase you can see that the red glow takes a bit to appear which indicates that it's quite slow to draw¹).

Also I'd guess that this is an area that's only recently been necessary to optimise in browsers.

_______

¹ Fun fact: It's a lot faster in IE than in Chrome ;-)

Once the page is rendered, the browser knows the (x,y,w,h) of every element in the DOM. It could store a reverse-map of that to quickly identify the DOM elements that contain any given (x,y), in the right nesting sequence. That could be used to optimize any pointer event. It could also have a special data structure just to identify DOM elements with :hover rules to specifically optimize hovers, which would help with both scrolling and just moving the mouse around the page.

There's probably a tradeoff between the time it takes to set up those data structures, the time they'd save, and the time it takes to handle the pointer and hover events without them. Maybe it's not worth it.

> There's probably a tradeoff between the time it takes to set up those data structures, the time they'd save, and the time it takes to handle the pointer and hover events without them. Maybe it's not worth it.

Memory consumption would also be an issue.

Clever. I see your point making sense, when you simplify this to just a pre-processing phase. But as you said, it just delays rendering needlessly. What Browser Vendors really want are online one-pass algorithms.

ygra: that's because IE implements that hack into it's core.

Nope. IE also renders the red glow noticeably faster than Chrome (i.e. less delay before it appears after hovering). There is no difference at all between hover on or off in terms of fps.

I know, right? Quake seemed to manage this stuff on my plodding beige box back in the day without sweating.

The excuse I hear from people who understand this stuff properly is that the quake engine didn't need to have a top of the line text rendering engine running on every surface, and this is what makes visual effects in browsers so expensive.

The excuse is that the DOM is huge and old and wasn't designed for performance. You can squeeze decent performance out of it but it's unbelievably easy to screw yourself over (example: listening to mousewheel anywhere on the page disables HW accelerated scrolling on webkit because it could presumably cancel the scroll).

Instead if you build an abstraction layer on top of the DOM that only exposes fast primitives you'll be better off.

>I know, right? Quake seemed to manage this stuff on my plodding beige box back in the day without sweating.

On the other hand, it handled just that. No dynaming styling, no CSS, no DOM, ...

Quake required a 75mhz Pentium, and you were lucky to get 20-30 fps. I don't remember getting anything like 60fps until a few years later with GLQuake and a Pentium II.

not true, I used to play on a 486DX, you did need a whopping 16mb of ram for it to run acceptably though.

I think we're both right. :)

I believe the official system requirement was a Pentium 75, though in reality you could run it on a 486DX pretty well if you had a VESA local bus video card, etc.

(I think I remember running it pretty horribly on a 486SX, like 3fps...)

Oh, the memories!

According to a few people both IE11[1] and Firefox[2] disable hit testing on scroll if you don't move your cursor while scrolling.

[1] http://www.thecssninja.com/javascript/pointer-events-60fps/c... [2] http://www.thecssninja.com/javascript/pointer-events-60fps/c...

It looks to me like Firefox already does this, only better - when scrolling stops, it not only reënables hover, but also applies its effects immediately. With the JS solution, anything the cursor lands on will only hover once the mouse moves again.

So this is from HTML5Rocks, I go to their site and in the footer. "This is a Google Project"

I want to subscribe to their articles, Twitter? No, Google Plus? No,... they only have RSS.

Now I wish there was a Google product that works with RSS.

Why are people obsessing over Google Reader as the only way to subscribe to RSS? There are a ton of alternative RSS readers around. I'm currently http://feeder.co/, it's a Chrome extension.

But HTML5Rocks is a Google project. It would make sense for them to use Google's replacement for RSS which is Google+. Instead they are continuing to use RSS.

Since when is Google+ a "replacement for RSS"? Since when did even Google announce that?

why is hover detection slow? i know browser devs are way behind the times... but three things:

* the browser can implement this optimisation

* spatial partitioning maybe is a much better general solution. the 2d aabb case is extrememly fast and can handle checks against 10000s of boxes per ms with good memory layout

* stagger checks across frames if more optimisation is needed when there are say, 100000s boxes to test (maybe? i'm skeptical even that would be especially slow)

Not much of an effect on my site's timeline (Chrome 31), maybe even a little worse than not having it.

Perhaps the demo "paints" a false picture considering that most sites don't have the same simplicity/symmetry of hoverable elements.

Opera probably already does something like that as scrolling in it is smoother than in FF on my machine even with the "disable hover"

Firefox seems to be exceptionally slow with rendering the drop shadow already, i.e. even scrolling without any hover is awfully slow here.

I still read !important as "not important" sometimes. Was probably a poor choice of a keyword for that purpose.

Yeah, who decided "!" meant "not"? That's just weird ;)

Well :) I like that more than something like this, in the spirit of Objective-C:

[a isNotEqualToIntegerWithSign:b]

(a parody of course)

Reply on news.ycombinator.com