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