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)
Core
Graphics: ImageLib
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
Comment 2•24 years ago
|
||
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.
Comment 3•24 years ago
|
||
When you right click on the page Mozilla gives you view frame source options, but the page doesn't seem to contain any frames.
Comment 4•24 years ago
|
||
Comment 5•24 years ago
|
||
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.
Comment 7•24 years ago
|
||
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
Comment 9•24 years ago
|
||
thanks tor, over to imagelib
Assignee: asa → pnunn
Status: UNCONFIRMED → NEW
Component: Browser-General → ImageLib
Ever confirmed: true
QA Contact: doronr → tpreston
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
*** Bug 64401 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 12•24 years ago
|
||
Fixed for gtk with the patch in bug 61410. win32 might want to utilize a similar fix.
Comment 13•23 years ago
|
||
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.
Comment 14•23 years ago
|
||
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!
Comment 15•23 years ago
|
||
it crashed me 2001030505 win98 build
Comment 16•23 years ago
|
||
confirming crash on NT build 2001030505!
Assignee | ||
Comment 18•23 years ago
|
||
<p class="broken record">I don't have a win32 development box</p>.
Comment 19•23 years ago
|
||
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.
Assignee | ||
Comment 20•23 years ago
|
||
*** Bug 71694 has been marked as a duplicate of this bug. ***
Comment 21•23 years ago
|
||
*** Bug 65716 has been marked as a duplicate of this bug. ***
Comment 22•23 years ago
|
||
*** Bug 89028 has been marked as a duplicate of this bug. ***
Comment 23•23 years ago
|
||
Comment 24•23 years ago
|
||
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
Comment 25•23 years ago
|
||
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.
Comment 26•23 years ago
|
||
*** Bug 103285 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 27•23 years ago
|
||
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).
Assignee | ||
Comment 28•23 years ago
|
||
Assignee | ||
Comment 29•23 years ago
|
||
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
Assignee | ||
Comment 30•23 years ago
|
||
Comment 31•23 years ago
|
||
Comment on attachment 52359 [details] [diff] [review] no tile cache, just a DrawCompositeTile sr=blizzard
Attachment #52359 -
Flags: superreview+
Comment 32•23 years ago
|
||
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+
Comment 33•23 years ago
|
||
Let's get this puppy in. Should also help remote-display performance.
Keywords: mozilla0.9.6
Assignee | ||
Comment 34•23 years ago
|
||
Checked in. Leaving bug open for win32/macos work.
Comment 35•23 years ago
|
||
Would a fix for bug 32736 also help Linux times? (If so, a dep might be an okay idea.)
Comment 36•23 years ago
|
||
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.
Comment 37•23 years ago
|
||
I'll file a port to Xlib toolkit tomorrow ...
Comment 38•23 years ago
|
||
note: (win platform) fixed scrolling & 100% cpu in bug 98252. build 2002-01-10-03.
Comment 39•23 years ago
|
||
Isn't it fixed now too?
Comment 40•23 years ago
|
||
Could we close that one now ? (wfm: 2202 01 27 08/win98). /jc
Updated•22 years ago
|
Attachment #52359 -
Attachment is obsolete: true
Comment 41•22 years ago
|
||
Resolving WORKSFORME per comments.
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: mozilla0.9.6 → testcase
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•