[Webkit-unassigned] [Bug 149997] Implement iterator for traversing composed DOM

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=149997

--- Comment #11 from Ryosuke Niwa <rniwa at webkit.org> ---
(In reply to comment #9)
>
> > For moving out of a slot, you find the assigned slot in O(1) as shown above,
> > and check whether you're the last one in the assigned nodes list or not.  If
> 
> Yeah. That's what the patch does.
> 
> > you're the last assigned node, then just move to the next node from the
> > slot. If the slot from which you're moving out is assigned to another slot,
> > then you into that slot's next assigned node. If we're the last slot
> 
> I'm maintaining the shadow stack to cache the assigned node index within the
> current slot. This allows moving to the slot's next assigned node in O(1).
> 
> A way to sort-of do this stacklessly (though I'm not sure if that is what
> you are arguing for) would be to walk the real siblings of the current slot
> assignee and find the next one in the same slot. This is much slower since
> we are doing hash lookups vs indexing to array. It also has bad worst case
> if nodes are assigned to mixed slots (like ABCABCABC.

Oh I see. Thanks for the clarification.

> If we are maintaining a stack and want to support arbitrary starting state
> for the iterator then we need to have function to synthesize the stack
> without traversing the tree. That's what initializeShadowStack() is about.
> 
> Note that it doesn't get called at all if you use shadowTreeDescendants()
> and is almost never called for shadowTreeChildren() (since there is a fast
> path that avoids it).

Okay. Can we avoid traversing up the shadow ancestors when the current shadow DOM doesn't have any slots? I'm mainly concerned about the performance implication of function invocations on builtin shadow DOMs (for input elements, etc...) without slots since they're a lot more common than shadow DOM with slots.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151013/ae73f864/attachment.html>