Like `nsRange`, `StaticRange` instances should also be reused as far as possible
Categories
(Core :: DOM: Core & HTML, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox75 | --- | fixed |
People
(Reporter: masayuki, Assigned: masayuki)
References
Details
Attachments
(1 file)
When we start to dispatch beforeinput event with supporting InputEvent.getTargetRanges(), editor needs to compute the ranges and then, need to create StaticRanges to represent the target ranges. However, it may cause performance regression due to:
- computation cost of target ranges.
- allocation cost of
StaticRangeinstances. - initializing cost of
StaticRangeinstances including computingstartOffsetandendOffsetfor fixing them. - allocation cost of array of
RefPtr<StaticRange>.
In these necessary cost, we can avoid the 2nd cost with same approach as bug 1612085.
|
Assignee | |
Comment 1•4 years ago
|
||
When we support InputEvent.getTargetRanges(), editor needs to create
StaticRange instances at starting to handle every edit operations/commands.
Therefore, we need a hack for saving allocation cost like nsRange.
This patch moves nsRange::MaybeCacheToReuse() and nsRange::Shutdown() to
AbstractRange to reduce copy&paste same code into nsRange and StaticRange.
However, Create(nsINode*) and Release() are duplicated unfortunately.
Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/937ce62849e0 Make `StaticRange` instances reused as far as possible like `nsRange` r=smaug
|
||
Comment 3•4 years ago
|
||
| bugherder | ||
Description
•