5 ms·

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 hov

by ygra 13y ago

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

DougWebb 13y ago
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.
- 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 ago
  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.
X4 13y ago
ygra: that's because IE implements that hack into it's core.
- ygra 13y ago
  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.

by ygra 13y ago

DougWebb 13y ago

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.

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

X4 13y ago

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

ygra 13y ago
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.