33709 - mozilla freezes for seconds on nic.fr homepage

Status: VERIFIED DUPLICATE of bug 31044

(Core :: Graphics: ImageLib, defect, P3)

Description

[Hervé Renault]

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)

Comment 1

[R.K.Aa.]

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..

Comment 2

[R.K.Aa.]

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.

Comment 3

[Hervé Renault]

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.

Comment 4

[Matthew Mastracci]

Attachment: Minimum testcase for bug (description follows)

Comment 5

[Matthew Mastracci]

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.

Comment 6

[Asa Dotzler [:asa]]

-> imagelib

Comment 7

[pnunn]

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


 

Comment 8

[Matthew Mastracci]

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)

Comment 9

[Matthew Mastracci]

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.

Comment 10

[Matthew Mastracci]

Sorry, more spam.  33428 is a dup as well.

Comment 11

[dcone (gone)]

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 ***

Comment 12

[gordon]

*** Bug 34313 has been marked as a duplicate of this bug. ***

Comment 13

[Alan S. Jones]

verified dupe