Closed Bug 64188 Opened 24 years ago Closed 22 years ago

Page with small png in table background is slow to display

Categories

(Core :: Graphics: ImageLib, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mra, Assigned: tor)

References

()

Details

(Keywords: perf, testcase)

Attachments

(2 files, 2 obsolete files)

The jedit.sourceforge.net page takes a long time to load and display. It seems
to be the display part which is taking the time. iconizing/deioconizing,
bringing the page to the front, etc. also take a long time.

The CPU usage goes up to 100% and stays there for about 200 seconds on my
machine. During this time the computer is unusably slow.

build 2000122805
*** Bug 64189 has been marked as a duplicate of this bug. ***
Build 2001010108 Linux
jedit takes around 40 seconds to load, computer is unresponsive during this time
and cpu is at 100%.  Scrolling, bringing the page to the front takes a long time.
When you right click on the page Mozilla gives you view frame source options,
but the page doesn't seem to contain any frames.
This problem is being cause by the background image.  Its a 1x3 pixel png, when
i change this image to gif the problem goes away.

If you want testcases showing this difference i can upload those too.
background.png is a 1x3 RGB+alpha image. I suspect alpha
compositing is the problem. This sounds like an older bug.
looks like a dup of bug 61410. mra@nortelnetworks.com, can you have a look at
that bug
and see if its a fit?
File: background.png (154 bytes)
  chunk IHDR at offset 0x0000c, length 13
    1 x 3 image, 32-bit RGB+alpha, non-interlaced
  chunk gAMA at offset 0x00025, length 4: 0.45455
  chunk bKGD at offset 0x00035, length 6: red = 255 green = 255 blue = 255
  chunk pHYs at offset 0x00047, length 9: 2833x2833 pixels/meter (72 dpi)
  chunk tIME at offset 0x0005c, length 7: 22 Dec 2000 05:54:43 GMT
  chunk IDAT at offset 0x0006f, length 23
    zlib:  deflated, 32K window, default compression
  chunk IEND at offset 0x00092, length 0
thanks tor, over to imagelib
Assignee: asa → pnunn
Status: UNCONFIRMED → NEW
Component: Browser-General → ImageLib
Ever confirmed: true
QA Contact: doronr → tpreston
I'll bet that images like this will start appearing more and more often.

It looks like Gimp made the image and Gimp has an interesting
feature/bug where merging its layers into one leaves the image with a
fully opaque alpha channel while flattening the image does not. There's
no visual indication in Gimp that an alpha channel exists; only when a
user tries to save the image in a format that does not support alpha
channels will the user get a warning. Gimp's PNG plugin will happily
save the image as presented.

While RGBA images like this are ineffifcient, they're not incorrect
either. Mozilla should treat the background image above the background
color specially, particularly if it must be tiled, as here.
*** Bug 64401 has been marked as a duplicate of this bug. ***
Fixed for gtk with the patch in bug 61410.  win32 might want to utilize
a similar fix.
You might want to know that under Solaris 8, Moz 0.8 plainly crashes on this URL
with an 'Illegal Instruction' message on the console. 
Disregard my last comment. This was a problem specific to the build I was using.
I got myself a new one and all is fine!
Keywords: perf
it crashed me 2001030505 win98 build
confirming crash on NT build 2001030505!
tor:
You want to take this one?
-p
Assignee: pnunn → tor
<p class="broken record">I don't have a win32 development box</p>.
People on win32, please shut down Mozilla, delete component.reg and fire it up
again. Does the page still crash?

If not, your crash may be related to bug 70900, which I experienced under Solaris.
*** Bug 71694 has been marked as a duplicate of this bug. ***
*** Bug 65716 has been marked as a duplicate of this bug. ***
*** Bug 89028 has been marked as a duplicate of this bug. ***
Attached file Testcase of the bug
The URL and the first testcase is no longer good for testing the bug - there
isn't the small png anymore.
I've attached a better testcase from the bug 89028.
OS: Windows NT → All
Hardware: PC → All
Summary: page takes a long time to display. → Page with small png in table background is slow to display
I recently discovered this bug, and would like to remind people that it
is still a problem. I've made a new test case of sorts:

http://katipo.co.nz/js/menus/slow.html

Alpha channels in pngs are likely to get more common since version 6 of a 
popular browser supports it. 

cf also the right sidebar in http://www.w3.org/Style/CSS/ - it eats the whole
cpu.
*** Bug 103285 has been marked as a duplicate of this bug. ***
The attached patch fixes the problem for gtk by making a replicated tile cache
of a decent size so we talk to the X server in reasonable sized chunks.

The w3 css page is bug 98252 (also fixed for gtk).
Attached patch replicated alpha tile cache (obsolete) — Splinter Review
Comment on attachment 52313 [details] [diff] [review]
replicated alpha tile cache

Ignore this - working on a more elegent solution (no cache)
Attachment #52313 - Attachment is obsolete: true
Comment on attachment 52359 [details] [diff] [review]
no tile cache, just a DrawCompositeTile

sr=blizzard
Attachment #52359 - Flags: superreview+
Comment on attachment 52359 [details] [diff] [review]
no tile cache, just a DrawCompositeTile

r=rjesup@wgate.com
Looks good.  Looks quite robust.  Someone
should try it with a mix of little-endian
and big-endian Xserver/clients (both ways) to
be absolutely sure, but I see no reason to hold
it up for that, just an idea for the verification phase.
Attachment #52359 - Flags: review+
Let's get this puppy in.  Should also help remote-display performance.
Keywords: mozilla0.9.6
Checked in.  Leaving bug open for win32/macos work.
Would a fix for bug 32736 also help Linux times?
(If so, a dep might be an okay idea.)
rjesup, I've tested this from a big-endian client
to a little-endian X-server and (assuming that the
attached testcase's background is supposed to the grey
and the drop-down menu testcase is supposed to be
blueish-purple) things seem fine.
I'll file a port to Xlib toolkit tomorrow ...
note: (win platform) fixed scrolling & 100% cpu in bug 98252. build 2002-01-10-03.
Isn't it fixed now too?
Could we close that one now ? (wfm: 2202 01 27 08/win98).

/jc
Attachment #52359 - Attachment is obsolete: true
Resolving WORKSFORME per comments.
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: mozilla0.9.6testcase
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: