Mozilla 2001-05-11-08-trunk on Solaris/Linux. Problem occurs with both PostScript and Xprint print systems - maybe cross-platform... ;-( Loading the example URL http://de.search.yahoo.com/search/photos_de?p={foto}&nice=foto&z=date&n=1000 usually takes less than 45secs - but attemping to print it takes far more longer than 20mins (!!) here (based on Xprint debug output it looks that most time is spend before any call to the print modules are made...).

Uh-oh... this issue is far more worse than I previously thought. Sun Ultra 5/333MHz/2MB 2ndLevelCache/384MB needs nearly two hours to print that page. Start mozilla (compiled with --enable-optimize), load example URL, print and after printing "ps" shows how _worse_ this issue is: -- snip -- % ps -ef | grep mozilla-bin mozilla 6893 17676 0 03:26:04 pts/8 0:00 /bin/sh ./run-mozilla.sh ./mozilla-bin gisburn 12375 17504 0 05:46:39 pts/5 0:00 grep mozilla-bin mozilla 6899 6893 92 03:26:05 pts/8 117:42 ./mozilla-bin -- snip --

confirming on linux rh62, I waited for this url for 10 min and declared it a hang and gave up. Maybe it takes two hours, but that's way beyond the threshold of anyone caring.

> confirming on linux rh62, I waited for this url for 10 min and > declared it a hang and gave up. Sure it "hangs" - AFAIK Mozilla's layout engine isn't multithreaded, see bug 61942 (IE has a significant advantage here because it can handle each window in a seperate process/thread)... ;-(((( > Maybe it takes two hours, but > that's way beyond the threshold of anyone caring. Uhm... what about testing this if it takes longer than 1 hour on a 800MHz machine ? I assume it would be usefull to mark this a "blocker" when _fast_ machines are still not able to print this page in a reasonable time...

I tested this with a 400MHz pentium II, I saw enough that we have an obvious problem. Any time past 10 min. is irrelavant, kinda like batting in more runs when you're ahead 12-0, who cares at that point.

> I tested this with a 400MHz pentium II, I saw enough that we > have an obvious problem. Any time past 10 min. is irrelavant, > kinda like batting in more runs when you're ahead 12-0, who cares > at that point. 1. Agreed... but having the precise value how long it takes can give us hints how "good" the improvements by upcoming patches are... 2. Can someone check this on Win32/Mac, please ? I assume this bug is All/All... ;-(

I think this is due to some large pictures and the output ascii can make this very slow. Imagelib changed so that printing will use the native size of the image instead of the scaled down image used by the screen. This means that alot of memory can be used, and for Postscript expecially, very large PS files are created and sent to the printer. This can make things very slow or even crash some PS devices. I am duping this against 68865 because I think its the same issue. *** This bug has been marked as a duplicate of 68865 ***

verified.

dcone: I don't think this is a problem in a specific print module. It looks like most time (~110mins in the 2hour case, e.g. 11/12 !!) is spend _before_ the first BeginPage() in the matching print module get's called. The final printing of pages is very fast (<=10mins for PostScript, <=7mins for Xprint)...

Its not the print module.. its the loading of the image.. and then the output of the image can take time also. If the native image is large.. then the image is re-downloaded.. this can take a ton of time.. and system resouces. The Postscript module would be the most stressed.. but does is not the problem. It is the size of the image downloaded.

dcone: The example page loads in <=2mins, printing it takes ~120mins... this is is a factor of _60_... are you really sure that this is a problem in the print module ?

you say.. It looks like most time is before the first BeginPage, this is correct. the majority of the time is spent loading the images. All the images on this page are loaded at there native size. Also with printing, there are two reflows, which means things can be loaded twice (the reason we do two reloads is another subject). So with this page, I find I can wait a very long time for the screen to load, over 5 minutes sometimes. Printing can take over 2x this time in the best of cases. Then if your doing postscript.. the full image is created sent to the printer, scaled and then printed. This can contribute also, depeending on the printer. Some printers are fast, some are slow. Anyway, I think the major problem with this page are the images.. which is already reported.. and Pavlov is looking into. We need to be able to print the cache and scaled images.. this will cut the time down to greater than 5 minute loads I am experiencing in the normal case. The bug number is 77155 *** This bug has been marked as a duplicate of 77155 ***

dcone: bug 77155 is Win2000 platform... is this the correct bug ? IF yes... bug 77155 should be Platform/OS = All/All...

v