New issue
Advanced search Search tips

Issue 684940 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 798908



Sign in to add a comment

We should have layout tree version for layout tree traversal in editing

Project Member Reported by yosin@chromium.org, Jan 25 2017

Issue description

When I introduce ntroduce SynchronousMutationObserver::didChangeAttribute()[1], it causes performance regression[2].

The objective of didChangeAttribute() is tracking DOM tree version for sanity checking. It is not critical to get rid of didChangeAttribute().

As of January 2017, following classes use dom tree version:
 - DraggingImageBuilder (for sanity); attribute change doesn't affect
 - EphemeralRange (for sanity); attribute change doesn't affect
 - GestrueManager
 - LayoutView (for hit test cache)
 - NodeIndex (for sanity); attribute change doesn't affect
 - PositionIterator (for sanity); attribute change doesn't affect
 - RangeBoundaryPoint (for invalidation); attribute change doesn't affect
 - SelectionTemplate (for sanity)
 - VisiblePosition (for sanity)
 - XPath

Some classes are valid on attribute change, so we can allow attribute modifications
during life time of them.

This can be done with introducing m_domTreeVersionWithOutAttribute change.

See also Element::attributeChanged() which is an origin of propagating attribute change.


[1] http://crrev.com/2641803003 introduce ntroduce SynchronousMutationObserver::didChangeAttribute(
[2] http://crbug.com/684394 Perf regression on modify-element-title
 
Owner: yosin@chromium.org
Status: Assigned (was: Available)
This is something I've been wondering about recently. We could split DOM tree version into hierarchical parts, or even independent parts. I think if you can show things get faster this is worth doing. The hard part is working out the subtle implicit dependencies here.

BTW, could you tidy this up a bit? The question is interesting but it's not very actionable.

Comment 2 by yosin@chromium.org, Feb 18 2017

Owner: ----
Status: Available (was: Assigned)
Summary: We should have DOM tree version without attribute change. (was: It DOM tree version without attribute change useful?)
Document::m_domTreeVersion is incremented by every DOM tree structure changes, insert, remove, change text data, change attribute.

Typical usage of dom tree version is invalidating cached date when dom tree version changed. Number of clients observing dom tree version don't care about attribute changes.

This means clients don't care about attribute changes do redundant cache invalidation.

Once we have dom tree version w/o attribute change, we can omit such redundant cache invalidation.




 
Project Member

Comment 3 by sheriffbot@chromium.org, Feb 21 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 4 by yosin@chromium.org, Feb 23 2018

Components: -Blink>DOM Blink>Editing>Selection
Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)
Summary: We should have layout tree version for layout tree traversal in editing (was: We should have DOM tree version without attribute change.)
Change to Blink>EditingSelection

Editing needs layout tree version for traversing tree with layout object
Blocking: 798908
So I'm not the first one thinking of adding layout tree version.

Sign in to add a comment