379672 - Typing into OkCupid textarea is laggy (involves float, onkeypress that sets innerHTML)

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Jesse Ruderman]

Attachment: simple testcase

Steps to reproduce:
1. Load the testcase.
2. Focus the textarea.
3. Bang on the keyboard for a few seconds.

Result: Lag; it takes seconds for Firefox to catch up.

Expected: No lag.

This regressed, or at least became much worse, starting in 2007-05-01 nightlies.  

About 90% of the time is spent under nsDisplayList::Paint, with 70% of that under nsCSSRendering::PaintBorder.

This makes typing messages in OkCupid painful, because you can't see what you're typing unless you slow way down.  (The testcase only captures about a third of the pain.)

I'm curious what the float:left has to do with the slowness.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

This is pretty weird; I don't see any problems with this on win32.  I'll try on mac; there could be something weird going on with that platform.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

FWIW, we've certainly had "slow typing" issues in Cocoa widgets before; iirc they've typically been Gecko doing too much extra redrawing/spellchecking/js counting, etc., and all the extra work has just been more expensive in Cocoa widget.

Comment 3

[Gábor Stefanik]

"PC/Mac OS X"? I didn't know that we support Hackintosh! :) Switching platform to Mac/Mac OS X.

Comment 4

[Jesse Ruderman]

We've been using "PC/Mac OS X" to represent Intel Mac.  (Using the "Hardware" field to really mean "CPU Architecture", since otherwise it doesn't mean much.)

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Two notes:

1. The testcase seems to work fine in OSX with a recent (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a6pre) Gecko/20070607 Minefield/3.0a6pre) version of Minefield.

2. The bug report seems related to bug 384231 - maybe a dupe?

Comment 6

[Jesse Ruderman]

The testcase still shows the problem for me.  Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a6pre) Gecko/20070611 Minefield/3.0a6pre

Comment 7

[Mike Connor [:mconnor]]

punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

So from my profile, we're basically spending a bunch (25%) of time essentially filling rectangles -- the background of the textfield, the blinky cursor, etc. Then we're spending another 10% drawing native widgets, and another 5% drawing the text glyphs.  Another 5% is spent drawing the spellcheck underlines.

I tried optimizing the rectangle rendering to call CGContextFillRect -- as far as I know, the fastest way to fill a rectangle on OSX -- and it made very little difference.  The rectangles are all integer aligned.

That said, I only see the problem if I really bang on the keyboard very quickly, and let the text drag out without any spaces (thereby totally blowing the text cache, among other things).  Not sure what to do about this.

Comment 9

[Jesse Ruderman]

> That said, I only see the problem if I really bang on the keyboard very
> quickly [...]

It's much worse on the actual site than in the testcase I attached.

Comment 10

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Punting; can't reproduce/debug easily.

Comment 11

[Jesse Ruderman]

WFM with the testcase in comment 0, and WFM on the current okcupid site.  Testing with a Mac trunk debug(!) build.