Closed Bug 73252 Opened 23 years ago Closed 23 years ago

Tivo.com locks up mozilla during redraw

Categories

(Core :: Layout, defect, P2)

PowerPC
Mac System 9.x
defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: mikepinkerton, Assigned: attinasi)

References

()

Details

(Keywords: perf, platform-parity)

Attachments

(3 files)

- go to http://www.tivo.com/home.asp (the non-flash version)

- page is very slow to load
- bring another window in front then bring tivo.com back to the front. watch the 
app lock for about 10 seconds handling the redraw
- scrolling this page is miserable and takes several seconds to get any response 
from the app

win32 is fine for some reason. when locked, it appears to be in various parts of 
table painting code. even with saari's libpr0n code, it still happens.
since their front page hilights a partnership with aol-tw, i think we might want 
to fix this one up.
Attinasi, when you get your mac, we can look at this together.
Assignee: karnaze → attinasi
Target Milestone: --- → mozilla0.9.1
I'll look at it when I get my Mac, but in the meantime, can somebody attach a
stack trace of where it locks up?
it does really lock up per se, it just takes _forever_ in the table drawing code. 
It does eventually finish, so there isn't really one place that it "freezes". I 
did did several samples with macsbug while it was "locked" and came up with 
various places in table painting.

To the user's eyes, though, the app is locked up.
I guess the best we can do then is pressure purchasing to rush my G4 ;)
Yup - I see the same thing on my Mac build (OPT) - Windows is fine. I will 
investigate.
Severity: critical → major
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Moving P2 and P3 bugs to 0.9.2
by mandate, moving non-crashers and non-datalossers to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
i think a 10-second hang redrawing the window is just as bad as a crasher! :(
I agree it is bad, but when I crash it generally takes me longer than 10 seconds
to resume my browsing ;)

Seriously, I hope to get to this before too long, but I have my marching
orders... (notice this only got pushed out to 0.9.3 and not 1.0) If I get past
my 4 0.9.2 bugs, and field the inevitable new issues that arise, then I will
jump on this one next.
Feeling like i need to justify my Mac, so I'm pulling it back up to 0.9.2
(really, I only have two others so it seems reasonable).
Target Milestone: mozilla0.9.3 → mozilla0.9.2
I'm reproducing a similar problem on another site: www.poweronsoftware.com
Go to this page and drag vertical scroll bar. The page is painted very slowly.
HTML code of the page shows an area map inside various TD's. Need to do further
troubleshooting.
The TIVO page is really slow because of the background images on the table. They
ahve a 1X1 spacer image as the background image on each of the tables on the
page - removing those makes this page paint fast.

Interestingly, in Quirks mode we push the background image from the table to the
cells, and then it gets tiled in each cell. This is obviously costly to paint on
the Mac. One option is to remove that quirk (which is a terrible thing anyway,
and IE does not do it).
I thought we did image tiling for performance with small, repeated background 
images? Why isn't that kicking in here?
The poweronsite site contains a tall bg image (18 px wide x 5184 px height)
applied via css to the body. If this reference is removed, the page scrolling is
greatly improved.
We do have image tiling optimizations, as far as I know... but if it gets 
pushed into the cell we probably re-tile for each cell. But maybe that is 
broken now, CC'ing pavlov for his input.

So it gets faster if either 1pixel spacer is removed or the very tall image?
With the eVineyard page, I made a local copy and it paints fast just like it is
(with a base href added, of course). So, I'm not sure what is up with that page,
but I think it shoudl probably get another bug for now - I'll open one.
bug 84234 opened on eVineyards issue since it appears to be different - for now
anyway.

For this bug we have two problems:

1) A very large background image that is tiled is very slow to paint.
2) Putting a small transparent GIF on the background of a table make painting
very slow.

For [1] I don't think I can do much - maybe we can improve the performance of
the imagelib or image rendering code, but layout has nothing to do with this.
Maybe pavlov or saari can look, or maybe we should open a new bug (or find an
existing one).

For [2] I'd like to determine if the problem is from the image painting code,
the style-propagation from the table to the cells, or a combination. I'll
continue to investigate this, and hopefully the image folks will too. 
The problem really appears to be with very small images that have to be tiled
very many times to fill the cells or table.

I created a testcase with a 25 X 25 table that has a background on the table
itself. In Quirks mode, this background is pushed to each cell, in standard mode
it is not. In either mode, if the image is a 1 X 1 pixel spacer GIF then it is
very slow to repaint. If instead I use a larger image that does not need to be
tiled to fill the cell or table, like the Mozilla.org banner image, then in
either mode the painting is fast. I think thus that the problem is with the
image tiling performance.

I'll attach the testcase for others to check out. (Does anybody know how to
profile on the Mac???)
Whiteboard: rtm stopper
the tiling code on windows and mac is slow as shit (its done in an XP manor that 
is really slow).  it should be fairly easy to make the windows and mac code impl 
the same tiling apis as the unix code, which should make this speedup quite a 
bit.
Keywords: perf
pav, I don't know what I can do with this - your comment makes me think you
might have an idea. Do you want it, or do you have another bug on tiling
performance that I can depend on?
Depends on: 86694
I opened a new bug on the tiling performance, and this bug now depends on that one.
No longer depends on: 86694
Updating milestone to match the bug that this depends on
Depends on: 86694
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Here's another site using a very tall image (w21 x h7999) assigned as a
background image. 

http://www.photowebber.com/Product/prodOverview.html

On the Mac, scrolling up and down on this page is sluggish in N6 but speedy in 4.77.
cleared 'rtm stopper' from status whiteboard (since it is not going to stop the 
release)
Whiteboard: rtm stopper
Scrolling performance is poor on this page too. HTML code shows multiple
backgrounds on the different tables used. One of the background used is a 1 x 1
transparent gif.

http://www.hallmark.com/hmk/Website/Shopping/sh_productdetail.jsp?BV_SessionID=@@@@0358595932.0993193434@@@@&BV_EngineID=dallelffkglbedbfchcgg.0&fromPage=/Website/Shopping/sh_hf_home.jsp&CONTENT_KEY=BNET&CONTENT_TYPE=PRODUCT
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla1.0
Blocks: 104166
Tivo loads and paints great now, and so does evineyards.com. Marking FIXED
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
so what changed?
bug 86694 was fixed.
Marking verified in the Mac OS X and OS 9 Oct 20th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: