5 ms·
60fps scrolling using pointer-events: none
- Xcelerate 13y agoPerhaps 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.
- ygra 13y agoYou 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 ;-)
- DougWebb 13y agoOnce 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.
- pcwalton 13y ago> 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.
- X4 13y agoClever. 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.
- X4 13y agoygra: that's because IE implements that hack into it's core.
- ygra 13y agoNope. 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.
- JonnieCache 13y agoI 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.
- peterhunt 13y agoThe 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.
- coldtea 13y ago>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, ...
- JohnBooty 13y agoQuake 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.
- phpnode 13y agonot true, I used to play on a 486DX, you did need a whopping 16mb of ram for it to run acceptably though.
- JohnBooty 13y agoI 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!
- ahrjay 13y agoAccording 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/comment-page-1#comment-7528 http://www.thecssninja.com/javascript/pointer-events-60fps/c... [2] http://www.thecssninja.com/javascript/pointer-events-60fps/comment-page-1#comment-7562 http://www.thecssninja.com/javascript/pointer-events-60fps/c...
- panic 13y agoI'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.
- yason 13y agoI'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.
- Sarkie 13y agoSo 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.
- FooBarWidget 13y agoWhy 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/ http://feeder.co/, it's a Chrome extension.
- sp332 13y agoBut 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.
- FooBarWidget 13y agoSince when is Google+ a "replacement for RSS"? Since when did even Google announce that?
- yread 13y agoOpera probably already does something like that as scrolling in it is smoother than in FF on my machine even with the "disable hover"
- ygra 13y agoFirefox seems to be exceptionally slow with rendering the drop shadow already, i.e. even scrolling without any hover is awfully slow here.
- babby 13y agoConsidering 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 http://userscripts.org/scripts/show/185715
- matthewmacleod 13y agoHmm. 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.
- untilHellbanned 13y agoNot 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.
- mojuba 13y agoI still read !important as "not important" sometimes. Was probably a poor choice of a keyword for that purpose.
- jheriko 13y agowhy 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)
- mistercow 13y agoIt 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.