Closed
Bug 73252
Opened 23 years ago
Closed 23 years ago
Tivo.com locks up mozilla during redraw
Categories
(Core :: Layout, defect, P2)
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.
Reporter | ||
Comment 1•23 years ago
|
||
since their front page hilights a partnership with aol-tw, i think we might want to fix this one up.
Comment 2•23 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•23 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•23 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•23 years ago
|
||
I guess the best we can do then is pressure purchasing to rush my G4 ;)
Assignee | ||
Comment 6•23 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•23 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Assignee | ||
Comment 7•23 years ago
|
||
Moving P2 and P3 bugs to 0.9.2
Assignee | ||
Comment 8•23 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•23 years ago
|
||
i think a 10-second hang redrawing the window is just as bad as a crasher! :(
Assignee | ||
Comment 10•23 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•23 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•23 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•23 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•23 years ago
|
||
Comment 15•23 years ago
|
||
I thought we did image tiling for performance with small, repeated background images? Why isn't that kicking in here?
Comment 16•23 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•23 years ago
|
||
Comment 18•23 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•23 years ago
|
||
i see the same problems on http://www.evineyard.com/home/default.asp?s=wine
Assignee | ||
Comment 20•23 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•23 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•23 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•23 years ago
|
||
Reporter | ||
Comment 24•23 years ago
|
||
http://www.mozilla.org/performance/mac-performance.html is a great reference
Updated•23 years ago
|
Whiteboard: rtm stopper
Comment 25•23 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.
Assignee | ||
Comment 26•23 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 | ||
Comment 27•23 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•23 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•23 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•23 years ago
|
||
cleared 'rtm stopper' from status whiteboard (since it is not going to stop the release)
Whiteboard: rtm stopper
Comment 31•23 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
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla1.0
Assignee | ||
Comment 32•23 years ago
|
||
Tivo loads and paints great now, and so does evineyards.com. Marking FIXED
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 33•23 years ago
|
||
so what changed?
Assignee | ||
Comment 34•23 years ago
|
||
bug 86694 was fixed.
Comment 35•23 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.
Description
•