151682 - ResizeView() invalidates too much when typing in a text widget

Status: NEW

(Core :: Web Painting, defect, P2)

Description

[kinmoz]

This bug was filed as an offshoot of bug 141900 (Text entry fields in forms
excruciatingly slow) to address the one remaining issue caused by
nsViewManager::ResizeView().

If you turn on paint flashing and type inside a textarea, you'll notice that we
invalidate and repaint the entire textarea for each character we type.

In bug 141900 comment 21, [e-mail] says that this is a hack to
compensate for the fact that layout does not invalidate all the areas it needs
to when resizing a view.

We need to address this problem some day.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Taking

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Hey, I thought I was the owner of views now.

Comment 3

[:deanis74]

Would this be why the caret disappears when typing in the url bar, and jumps to
the front when auto-completing, or is that a separate issue?

Comment 4

[kinmoz]

Dean, the problem you mention is bug 151882, which was caused my turning on of
async updates for text widgets, I know the exact line that is causing the
problem, but I'm hoping to fix that issue in conjunction with bug 54153 since it
forces us to rethink when we should be redrawing the caret.

Comment 5

[:deanis74]

Thanks Kin, that's exactly it.

Comment 6

[Simon Fraser [no longer active]]

Attachment: Testcase (slow typing in semi-opaque textarea)

Testcase. This bug is probably the main reason why typing in textfields is
slow.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

er, taking!!!

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

To really fix this well we have to change ResizeView to paint NOTHING at all.
The problem is, suppose we have a positioned element with zero size which has
animated children. The positioned element's view will change size to fit all the
children as they move around. Even repainting the difference between the old and
new dimensions is wasteful. I think both positioning and resizing views should
paint nothing, leaving it up to layout to invalidate the frames involved.

Definitely 1.3alpha stuff. It will probably cause regressions for weeks while we
track down all the places where the code is currently depending on conservative
painting.

Comment 9

[Kevin McCluskey (gone)]

I agree, only layout has enough information to optimize the invalidation of
damaged areas so the viewmanager should not invalidate on Resize. 

Comment 10

[Carine Held]

Reproduced in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-CA; rv:1.0.2)
Gecko/20021120 Netscape/7.01. Testcase keword added.