Bug 145899
| Summary: | Poor scrolling performance with large complex table | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Gavin Sherlock <gsherloc> |
| Component: | Tables | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | cdumez, kling, koivisto, simon.fraser, zalan |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://www.yeastgenome.org/cgi-bin/FUNGI/alignment.pl?locus=YBR140C | ||
Gavin Sherlock
Go to bug url (http://www.yeastgenome.org/cgi-bin/FUNGI/alignment.pl?locus=YBR140C)
Wait for page to load
Scroll down
Expected results:
Smooth scrolling through the document
Actual results:
Often shows no rendered content for several seconds, pauses, stutters and locks up
Tested with release Safari and r185452
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
alan
This is a table heavy page. I bet that's the reason why the Web process locks up.
66 <table>
2500 <tr>
150K <td>
123K <tt>
Chromes handles it relatively okay. (better than WebKit trunk)
alan
While loading the page we spend significant amount of time in
pumpTokenizer (28%) -> SegmentedString::operator= (25%)
and WTF::Deque<SegmentedSubString>::destroyAll (11%)
Also Style::resolveTree() (11%)
After finished loading another round of style resolving kicks in with Style::resolve(37.2%) -> getUncachedPseudoStyle(13%)
While scrolling, we spend most of the time in cell painting -> text drawing.