11.80 KB, text/html
8.35 KB, text/html
TESTCASE: painting is fast with large background image, slow with small one (suggesting tiling is the problem)
25.68 KB, text/html
- 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.
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.
Moving P2 and P3 bugs to 0.9.2
by mandate, moving non-crashers and non-datalossers to 0.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).
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?
i see the same problems on http://www.evineyard.com/home/default.asp?s=wine
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  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  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???)
Created attachment 37455 [details] TESTCASE: painting is fast with large background image, slow with small one (suggesting tiling is the problem)
http://www.mozilla.org/performance/mac-performance.html is a great reference
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.
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?
I opened a new bug on the tiling performance, and this bug now depends on that one.
Updating milestone to match the bug that this depends on
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)
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
Tivo loads and paints great now, and so does evineyards.com. Marking FIXED
so what changed?
bug 86694 was fixed.
Marking verified in the Mac OS X and OS 9 Oct 20th build.