Closed
Bug 300797
Opened 20 years ago
Closed 20 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
()
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•20 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•20 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•20 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•20 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•20 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•20 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•20 years ago
|
Attachment #189399 -
Flags: approval1.8b4? → approval1.8b4+
| Assignee | ||
Comment 6•20 years ago
|
||
Fixed.
| Reporter | ||
Comment 7•20 years ago
|
||
FIXED, I assume.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•