54618 2011-02-16 22:35:15 -0800 Web Inspector: Need renderer hint on implementing hovered node highlight in WebCore. 2011-08-08 22:47:52 -0700 1 1 1 Unclassified WebKit Web Inspector (Deprecated) 528+ (Nightly build) All All RESOLVED WONTFIX P2 Normal --- 1 pfeldman webkit-unassigned hyatt jamesr simon.fraser oldest_to_newest 352616 0 pfeldman 2011-02-16 22:35:15 -0800 Summarizing chats that I've had on the IRC. Background: When you hover over an element in inspector, we paint node highlight. Different ports handle it differently, all ultimately calling inspector's drawNodeHighlight defined in WebCore: - Mac uses floating NSView in WebNodeHighlightView - Windows uses floating native window in WebNodeHighlight - GTK and Chromium simply issue repaint and stick inspector's drawNodeHighlight into their paint routines. - WebKit2 is pending implementation I'd like to unify the approaches and keep all the code in the WebCore. There are two scenarios where naive approach of putting drawNodeHighlight into FrameView does not work: - plugins that are on top of the screen - accelerated compositing We can give up the plugins one, but compositing still requires special handling. I am a rendering idiot and reaching out for your hints. As I see, we could do two things: 1. Bump element's zindex on hover in its style and call highlight code from the RenderObject 2. Somehow have additional RenderLayer that would paint highlight (1) has a side-effect of bringing node above other elements, but sounds simpler. It might be considered as either feature or a regression, I am not sure. (2) would be simply perceived as no regressions. On a side note, there is a pending request to make inspector highlight follow the moving / transforming elements, so (1) sounds more feasible to me, but I know nothing about rendering. What do I miss? 352955 1 simon.fraser 2011-02-17 09:12:06 -0800 >1. Bump element's zindex on hover in its style and call highlight code from the RenderObject That wont' work. > 2. Somehow have additional RenderLayer that would paint highlight I don't think you want that either. When accelerated compositing is off, you could get away with painting something "last" in the painting order. See ScrollView for some code that does this for overlay scrollbars and the pan indicator. When accelerated compositing is on, you'll need to render the highlight into its own GraphicsLayer which is above everything else. WebKit2 already has a notion of an overlay layer (it's used for the Find highlight), but we'd need to pipe something through for WebKit1. It would be nice if we could share the same "overlay" logic whether or not compositing is on, and have the GraphicsLayer part be hidden. 448441 2 pfeldman 2011-08-08 22:47:52 -0700 Implemented in WebKit.