Closed
Bug 300797
Opened 19 years ago
Closed 19 years ago
[FIXr]When typing in a wrapped paragraph, entire paragraph redraws on each keypress
Categories
(Core :: Layout, defect, P1)
Core
Layout
Tracking
()
RESOLVED
FIXED
mozilla1.8beta4
People
(Reporter: sfraser_bugs, Assigned: bzbarsky)
References
(Blocks 1 open bug, )
Details
(Keywords: perf)
Attachments
(1 file)
|
3.35 KB,
patch
|
sicking
:
review+
roc
:
superreview+
benjamin
:
approval1.8b4+
|
Details | Diff | Splinter Review |
When editing text in a textarea with wrapped text, we redraw the entire paragraph for each character that you type, even if the text wrapping didn't change. We should be able to optimize for common case of typing on the last line of a paragraph, when we know that only the current line needs to be redrawn. This will help some of the typing performance bugs (bug 272954, bug 272954).
| Assignee | ||
Comment 1•19 years ago
|
||
So I think what happens is that we get into nsTextFrame::Reflow, which happily invalidates the entire textframe before returning (see http://lxr.mozilla.org/seamonkey/source/layout/generic/nsTextFrame.cpp#5939). The reason we're reflowing all the in-flow textframes is that typing a character ends up calling InsertData() on the textnode, which ends up notifying of the text change with aAppend == PR_FALSE.
| Assignee | ||
Comment 2•19 years ago
|
||
So the problem is that editor insert transactions always call InsertData() on the textnode. Which is fine (and I see no reason to complicate editor by changing that), but the textnode easily has enough information in InsertData to know that it can convert this call to an AppendData call, which passes PR_TRUE for aAppend. Actually, I changed ReplaceData to do this, since InsertData just calls right through to ReplaceData. I also removed the unused #if 0 code that made AppendData call ReplaceData, since we really don't want it now. With this patch we repaint only the last two lines of the paragraph (they're the only ones we reflow now; we reflow the next-to-last one because all the block knows is that something changed on the last line, and the change may require the text to be pulled back up a line for all it knows). This should make the amount of reflow and painting O(1) instead of O(N) here.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #189399 -
Flags: superreview?(roc)
Attachment #189399 -
Flags: review?(bugmail)
| Assignee | ||
Comment 3•19 years ago
|
||
Simon, was there a second bug (other than bug 272954) that this should block? Comment 0 has bug 272954 twice...
Blocks: 272954
Priority: -- → P1
Summary: When typing in a wrapped paragraph, entire paragraph redraws on each keypress → [FIX]When typing in a wrapped paragraph, entire paragraph redraws on each keypress
Target Milestone: --- → mozilla1.8beta4
Attachment #189399 -
Flags: review?(bugmail) → review+
| Reporter | ||
Comment 4•19 years ago
|
||
Added 188318 to the dependencies. Patch looks good; I verified that now only the last 2 lines redraw. This seems to help Camino's pathological typing perf a little.
Attachment #189399 -
Flags: superreview?(roc) → superreview+
| Assignee | ||
Comment 5•19 years ago
|
||
Comment on attachment 189399 [details] [diff] [review] Proposed patch Requesting 1.8b4 approval. Pretty safe fix, makes us do a lot less work when typing.
Attachment #189399 -
Flags: approval1.8b4?
| Assignee | ||
Updated•19 years ago
|
Summary: [FIX]When typing in a wrapped paragraph, entire paragraph redraws on each keypress → [FIXr]When typing in a wrapped paragraph, entire paragraph redraws on each keypress
Updated•19 years ago
|
Attachment #189399 -
Flags: approval1.8b4? → approval1.8b4+
| Reporter | ||
Comment 7•19 years ago
|
||
FIXED, I assume.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•