pub struct FullHitTest {
pub hovered_nodes: BTreeMap<DomId, HitTest>,
pub focused_node: OptionDomNodeId,
}Expand description
Complete hit-test result across all DOMs, including the currently focused node.
Fields§
§hovered_nodes: BTreeMap<DomId, HitTest>§focused_node: OptionDomNodeIdImplementations§
Source§impl FullHitTest
impl FullHitTest
Sourcepub fn hovered_node_ids(&self) -> Vec<DomNodeId>
pub fn hovered_node_ids(&self) -> Vec<DomNodeId>
Every node under the pointer, FRONT TO BACK (9g-ii-e).
§Why this exists rather than the struct being exposed
FullHitTest is a BTreeMap of DomId to a HitTest that is itself
four more maps. Exposing that shape across the C ABI needs five map
types nothing else would use, and no application wants the shape - it
wants the ANSWER: what is under the cursor, nearest first. So the
accessors return that, the same trade get_hid_reports makes by
returning an owned vec rather than a borrowed slice.
Ordered by hit_depth, which WebRender and the CPU tester both fill
with a real z-order (0 = frontmost). That is a stronger ordering than
the NodeId one some call sites use as a proxy: two overlapping
absolutely-positioned nodes can have any id relationship, and the one
on top is the one with the lower depth.
Only the REGULAR hits: scroll frames, scrollbar parts and cursor areas are hit-tested separately and are not nodes an app would call “under the pointer” - a scrollbar is not the content beneath it.
Sourcepub fn topmost_node(&self) -> Option<DomNodeId>
pub fn topmost_node(&self) -> Option<DomNodeId>
The node nearest the user, or None when the pointer is over nothing.
What an app almost always means by “the hit test”: the topmost regular
hit. Cheaper than Self::hovered_node_ids because it does not sort.
Trait Implementations§
Source§impl Clone for FullHitTest
impl Clone for FullHitTest
Source§fn clone(&self) -> FullHitTest
fn clone(&self) -> FullHitTest
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more