319047 - Very slow rendering of pages

Status: RESOLVED DUPLICATE of bug 258136

(Firefox :: General, defect)

Description

[Mikulas Patocka]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8) Gecko/20051118 Firefox/1.5
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8) Gecko/20051118 Firefox/1.5

For some pages (long discussion forums on zena.centrum.cz are the most obvious example, however there are many more pages with this problem) Firefox on OS/2 loads the page very slowly. After nearly every line being parsed, it redraws the screen. As a result, much more CPU is spent on redrawing instead of parsing and the page doesn't load even in several minutes.

I have Pentium 200MHz. Redrawing the screen takes about half a second. When firefox redraws the screen after for line in a forum containing several hundreds of messages, it is unusable. The forum doesn't load even in several minutes.

This problem is probably OS/2-specific (OS/2 scheduler doesn't advance or lower thread priorities much).


Reproducible: Always

Steps to Reproduce:
1. Take a Pentium 200MHz (I'm not sure if it happens with faster) with OS/2 system.
2. Go to zena.centrum.cz, select an article with more than 100 discussion messages.

Actual Results:  
You wait many minutes to load the page and see screen constantly redrawing one-more line at a time.


Expected Results:  
When Firefox doesn't wait on slow network connection, it should not redraw screen excessively. It should devote all CPU power to parsing and redraw the screen only when parsing is done.

For example, in Links browser, I solved this problem by measuring redraw time and initiating next redraw after 15*last_redraw_time (or when the whole page has loaded). This way, the browser guarantees that no more than 1/15 CPU time is spent on redrawing while user experience is still accetable (while loading, simple pages redraw in small intervals, complicated pages redraw after longer time).


OS/2 Warp version 4, Fixpack 15
inetver: SOCKETS.SYS: 6.3000, AFOS2.SYS: 6.3000, AFINET.SYS: 6.3001

Comment 1

[Peter Weilbacher]

As you are talking about long pages this is a dupe of bug 258136.

The problem is known but we don't have a way yet to profile GCC code efficiently, the number of redraws is not the problem, you could try yourself by setting nglayout.initialpaint.delay to a high value, like 10000 (= 10s) or even higher.

*** This bug has been marked as a duplicate of 258136 ***