Tivo.com locks up mozilla during redraw

VERIFIED FIXED in mozilla1.0

Status

()

Core
Layout
P2
major
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: Mike Pinkerton (not reading bugmail), Assigned: Marc Attinasi)

Tracking

({perf, pp})

Trunk
mozilla1.0
PowerPC
Mac System 9.x
perf, pp
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
- 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.
(Reporter)

Comment 1

17 years ago
since their front page hilights a partnership with aol-tw, i think we might want 
to fix this one up.
Keywords: correctness, nsbeta1, nsCatFood, nsmac1, pp

Comment 2

17 years ago
Attinasi, when you get your mac, we can look at this together.
Assignee: karnaze → attinasi
Target Milestone: --- → mozilla0.9.1
(Assignee)

Comment 3

17 years ago
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?
(Reporter)

Comment 4

17 years ago
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.
(Assignee)

Comment 5

17 years ago
I guess the best we can do then is pressure purchasing to rush my G4 ;)
(Assignee)

Comment 6

17 years ago
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
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2
(Assignee)

Comment 7

17 years ago
Moving P2 and P3 bugs to 0.9.2
(Assignee)

Comment 8

17 years ago
by mandate, moving non-crashers and non-datalossers to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
(Reporter)

Comment 9

17 years ago
i think a 10-second hang redrawing the window is just as bad as a crasher! :(
(Assignee)

Comment 10

17 years ago
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.
(Assignee)

Comment 11

17 years ago
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

Comment 12

17 years ago
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.
(Assignee)

Comment 13

17 years ago
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).
(Assignee)

Comment 14

17 years ago
Created attachment 37265 [details]
TIVO page with table background images removed

Comment 15

17 years ago
I thought we did image tiling for performance with small, repeated background 
images? Why isn't that kicking in here?

Comment 16

17 years ago
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.

Comment 17

17 years ago
Created attachment 37268 [details]
background removed, page scrolls properly

Comment 18

17 years ago
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?
(Reporter)

Comment 19

17 years ago
i see the same problems on

http://www.evineyard.com/home/default.asp?s=wine
(Assignee)

Comment 20

17 years ago
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.
(Assignee)

Comment 21

17 years ago
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. 
(Assignee)

Comment 22

17 years ago
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???)
(Assignee)

Comment 23

17 years ago
Created attachment 37455 [details]
TESTCASE: painting is fast with large background image, slow with small one (suggesting tiling is the problem)
(Reporter)

Comment 24

17 years ago
http://www.mozilla.org/performance/mac-performance.html

is a great reference

Updated

17 years ago
Whiteboard: rtm stopper

Comment 25

17 years ago
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
(Assignee)

Comment 26

17 years ago
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?
(Assignee)

Updated

17 years ago
Depends on: 86694
(Assignee)

Comment 27

17 years ago
I opened a new bug on the tiling performance, and this bug now depends on that one.
No longer depends on: 86694
(Assignee)

Comment 28

17 years ago
Updating milestone to match the bug that this depends on
Depends on: 86694
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 29

17 years ago
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.
(Assignee)

Comment 30

17 years ago
cleared 'rtm stopper' from status whiteboard (since it is not going to stop the 
release)
Whiteboard: rtm stopper

Comment 31

17 years ago
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
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.4 → mozilla1.0

Updated

16 years ago
Blocks: 104166
(Assignee)

Comment 32

16 years ago
Tivo loads and paints great now, and so does evineyards.com. Marking FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 33

16 years ago
so what changed?
(Assignee)

Comment 34

16 years ago
bug 86694 was fixed.

Comment 35

16 years ago
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.