i'm sorry i've no time to investigate, but i would like to point you at this site. this page is looking really simple but something in it makes the whole moz freeze for at least 5 seconds on my PII-400 (256MB RAM) i'm using the latest moz binary at this time (on Linux SuSE 6.2)
that's odd..i have the latest nightly here as well and just tried that site after having started moz with a blank page. And it loaded fairly quick - about as quick as in NS4.7. I'm using a P120 so i usually notice veeery well if things are slow..
oops..me and my big..keyboard: There IS something strange. It loaded quick, but after typing this in 4.7 and "un-shadowing" moz - THEN it had kinda frozen...took 31 seconds to refresh that page.
doing some quick tests... _maybe_ the freeze is related to images because : a) i've saved the page on my disk (without images) and loaded it with no problem. b) i selected "block all images" in the prefs and then loaded it from the net and the problem does not show up ! note that once the page is loaded from the network (with images), it freezes each time you simply hide/unhide moz window.
The bug involves a big table (600x400 does it well) with a background containing a small, transparent GIF. The attachment demonstrates this bug fairly well. I believe this bug should be changed to the ImageLib category and be labelled as a performance bug, as the browser isn't hung - just taking a long time to render. As for severity, this is the first page I've seen that uses a transparent gif background for a table, so it's not critical. It does lock up the browser for a fair amount of time, however.
Assignee: cbegle → pnunn
Status: UNCONFIRMED → NEW
Component: Browser-General → ImageLib
Ever confirmed: true
QA Contact: asadotzler → elig
I can see the problem. Much thanks for the attached testcase. It speeds up bug solving considerably... I've made a local version of the testcase, in http://jazz/users/pnunn/publish/afnic/testurlfast.html and testurlslow.html. I set the test up so the image files are local (take out the server speed as a factor) and set a background color for the page. The image causing the problem is the transparent image which is tiled in the table background. While we should be handling the table background tiling better than we do, the page designer should be aware that: 1> the table bkground transparent image isn't needed at all. The table is already transparent by default. 2> Tiling a one pixel image is extremely inefficient. If you need to tile a very small image (tiling is used to cover backgrounds in tables and pages), if you choose an 8x8 image or larger, your page load will speed up dramatically. I believe that multiples of 8x8 are the fastest. ------------- Don: This looks like another instance of the tiling problem. I left my test urls and images in http://jazz/users/pnunn/afnic. You are welcome to use them for test. -P
Assignee: pnunn → dcone
Target Milestone: --- → M16
It looks like this bug might occur more often than I thought - bug #34313 is a dup (I put a comment saying so - someone needs to mark it such). www.fileclicks.com uses the same transparent background image as well. Now, would it be possible for the tiling engine to aggregate smaller tiles into larger ones for performance? For instance, any image with a dimension less than 8 would be internally tiled into a temporary image with that dimension greater or equal to first, then tiled. A 1x1 image would become 8x8, 20x1 would become 20x8 and 3x3 would become 9x9. It would be something like: new_width = width * (8 / width + 1)
I've noticed a fair number of bugs that deal with tiled-image performance issues. Should this bug be changed to: Summary: [PERF] Tiled images slow rendering/scrolling If so, it looks like some of these would be dups: 34327, 31044 Looks like 31044 might be the same problem, but with some extra suggestions on how to fix it.
Sorry, more spam. 33428 is a dup as well.
It will be slow with small transparent GIFS.. I recently (today) checked in a change that will give each platform the option of putting in its own platform dependent speedup. Windows uses a PatBlt for example and speeds this problem up by ALOT. I will have to look into each platform for there solution to solve this. *** This bug has been marked as a duplicate of 31044 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
*** Bug 34313 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.