[Webkit-unassigned] [Bug 20831] Very slow <input type="search">. 100% CPU usage for each key press.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=20831





------- Comment #5 from john.engelhart at gmail.com  2009-01-03 20:59 PDT -------
(In reply to comment #4)
> Bad search field redrawing in the testcase filed as bug 23093.
> 
> John: if I extract the HTML you posted (with the garbage in the middle
> removed), typing in the search field seems fine. Please attach an HTML file
> that shows the problem using the Create New Attachment link above.
> 

I just retested this as requested.  I tested it on a late 2008 unibody MacBook
(2.0GHz) and a 1.5GHz PPC PowerMac.

The problem doesn't really manifest itself in any noticeable fashion on the
faster machine.  Only on the slower powerbook is it noticeable.  Just tried
forcing Safari.app to execute under Rosetta and it's slightly noticeable, but
still not to the degree that it is on the powerbook.

I'm afraid to really see this in action, you'll need to find yourself an old
PPC machine.  For grins, I tried it on an iPod touch, but it handles the text
input in a completely different way, so can't really test it that way
unfortunately.

IMHO, the machines are fast enough now that you can't really perceive a problem
any more.  However (and this is just a guy feeling) I think it still points to
an underlying performance problem, possibly in the rendering code.  Thinking
back, I remember digging a little bit more in to this, and I seem to remember
coming to the conclusion that it seemed like a case of 'over redrawing', that
each keystroke triggered a storm of unnecessary redraws.

My initial comment says that getting rid of the -webkit-gradient background
causes the problem to go away... does that ring any bells?  Something about
having a -webkit-gradient in the 'NSView' (sorry, I don't know webkit all that
well, but whatever is analogous to the cocoa NSView paradigm) hierarchy that
might be causing some over-zealous redraw/refresh?

So, just to be clear:  The problem still exists on my 1.5GHz PPC PowerBook, but
isn't noticeable on a 2.0GHz x86 late 2008 unibody MacBook.

Hmm, for grins, I just tried the example HTML unmodified in one table, and
commenting out the .alpha... CSS part in another tab on my MacBook, and then
typing in both search boxes.

Watching MenuMeter's CPU usage, the unmodified version does use a noticeable
(but small) amount of CPU, and the commented out version uses an undetectable
amount of CPU.  I suspect that a Shark.app session between the two versions
(unmodified, and .alpha... CSS commented out) would be revealing to someone who
knows the code base.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.