Open Bug 485446 Opened 12 years ago Updated 4 months ago

Optimize text frame selection

Categories

(Core :: DOM: Selection, defect, P5)

x86
All
defect

Tracking

()

People

(Reporter: cpearce, Unassigned)

References

(Depends on 3 open bugs, Blocks 1 open bug)

Details

(Keywords: perf)

Attachments

(2 files)

As per layout 2009 Q2 planning doc: https://spreadsheets.google.com/ccc?key=pF_tMaWf14QyuXltBtJtYdw&hl=en

Text frames has a bunch of bits in it to show whether anything inside it is selected. This allows us to follow a fast path when managing selection. The management of this is sometimes inefficient. We can end up doing a lot of O(n^2) operations.

Rework a small amount of text frame code to fix performance bugs dealing with very large text nodes. This is a prerequisite to getting rid of 4K node limits while parsing, and to simplifying text editing by making text inputs and textareas contain one really big text node.

Test case is attached. Try selecting text, it's really slow.
Bug 486072 may be related or a dupe of this?
But 486072 is definitely related.  See bug 486072 comment 9.
Blocks: 486072
Note bug 371839, by the way; you might want to read through the code there, and bug 371839 comment 7 in particular.  Should this be marked duplicate or dependent or whatever?
Blocks: 240933
Also note bug 449167.
Depends on: 449167, 371839
Blocks: 440641
I don't see any slowness when selecting the text (with the mouse, or by double clicking or by cmd + a) in the testcase, using:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090928 Minefield/3.7a1pre
I don't see any slowness either.
Do we need a new testcase or is this fixed or what?
I don't either, on the attached testcase, using a 2009-03-26 build.  I suspect the testcase or the steps to reproduce need changes...
Attached file a testcase
Set cursor somewhere in the first line, then scroll to the last line and
shift-click somewhere there.
ComparePoints is the problem here. It can be made a lot faster in this case even
without having a float/double location marker in the nodes.
Actually, that testcase shows more like the problem described in Bug 486072.
Depends on: 519657
Depends on: 533892
On recent trunk builds, the performance of the attached test cases seems acceptable.  This doesn't appear to have an effect on the performance of textareas which have a single text node (bug 240933), so I'm removing the dependency.
No longer blocks: 240933
Keywords: perf
Assignee: cpearce → nobody

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.