485446 - Optimize text frame selection

Status: NEW

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

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Testcase - selection is slow

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.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

Bug 486072 may be related or a dupe of this?

Comment 2

[Boris Zbarsky [:bzbarsky]]

But 486072 is definitely related.  See bug 486072 comment 9.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Also note bug 449167.

Comment 5

[José Jeria]

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

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

I don't see any slowness either.
Do we need a new testcase or is this fixed or what?

Comment 7

[Boris Zbarsky [:bzbarsky]]

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...

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Attachment: 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.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Actually, that testcase shows more like the problem described in Bug 486072.

Comment 10

[(no longer active)]

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.

Comment 11

[Jens Stutte [:jstutte]]

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.