Range overlap testing during table cell selection causes major performance slowdown

VERIFIED FIXED in M16

Status

()

Core
Editor
P3
normal
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: Charles Manske, Assigned: Charles Manske)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+][dogfood-])

(Assignee)

Description

18 years ago
Table cell selection works by putting each cell in its own nsRange object.
When multiple cells are selected, e.g., by using Ctrl (Cmd on Mac) + dragging
the mouse, the selection updating is extremely sluggish. It is easy to test
if we are in "table cell selection mode" by calling 
nsFrameSelection::GetTableCellSelection() or checking if the cell frame is
selected. If this is true, we should skip the range-overlap tests that are
slowing down cell selection.
(Assignee)

Comment 1

18 years ago
Nominating for beta2 and dogfood as without this fixed table selection is
essentially unusuable. The delays when selectin a cell are so long (e.g., 10
sec to select a block of about 25 cells on a 450mhz Pentium) that it will
confuse the user.
Keywords: dogfood, nsbeta2

Comment 2

18 years ago
yes, this is really awful -- we selected just a single row and it literally took 
8-10 seconds, ranges do not be calculated and analyzed within tables.

Updated

18 years ago
Target Milestone: --- → M16

Comment 3

18 years ago
Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2.
Whiteboard: [nsbeta2+][dogfood-]

Comment 4

18 years ago
sgafdggadsg
Assignee: mjudge → cmanske
(Assignee)

Comment 5

18 years ago
Checked in. 
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 6

18 years ago
verified in 6/4 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.