GIF image makes browser unresponsive in Linux

RESOLVED FIXED

Status

()

Core
ImageLib
RESOLVED FIXED
17 years ago
16 years ago

People

(Reporter: Hampton Maxwell, Assigned: Stuart Parmenter)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
Tested using Linux 2001121921/0.9.7+ on a dual p2-400.
The image at the url above makes the browser very sluggish, so that any action
that involves the image/window that image is loaded will respond very slowly.  

To reproduce:
Drag another window in front of the image (using opaque move). The window will
jerk instead of moving fluidly.
-or-
Load the image and resize the window so that you can scroll up and down.  Scroll
up and down using slider bar.  Scrolling will not be fluid as it should be.

One side effect of this bug is that pages with this image, namely:
http://www.evil3d.net/news/ will cause the browser to become unresponsive while
the page is being loaded.

By scrolling on the news url, I was able to reproduce the bug on a P4 1.5 GHz
WinXP machine.  Viewing the image by itself does not cause a noticeable
performance problem.

Comment 1

17 years ago
If it's definitely the GIF image causing the slowdown, then it sounds like bug
99636 (or some related bug).  However, on my system, the slowdown only seems to
occur when scrolling, I'm guessing this is actually a layout bug, possibly to do
with tables?  Or tables with images?
(Reporter)

Comment 2

17 years ago
I am fairly sure this is an image problem only.  I loaded the page with images
disabled and it performs just fine.  As I mentioned, the problem is really acute
on Linux - testing on WinMe I don't notice any problems, even scrolling the
whole page.  The reason you are only seeing the problem with the full page is
probably because the image occupies more screen space in that case so it takes
more time to compute the scrolling.

This is not a dupe of 99636 because it is not an animated gif and after the
image is loaded cpu usage is at 0%.

Comment 3

17 years ago
wfm moz 0.9.8 win2k, anyone else verify with a newer build ?
(Reporter)

Comment 4

17 years ago
WFM on WinMe, but not under Linux.  Changing OS -> Linux, updating summary to
reflect platform.

Changing link to a simpler testcase.
OS: All → Linux
Summary: GIF image makes browser unresponsive → GIF image makes browser unresponsive in Linux

Comment 5

16 years ago
the URL is gone.

this problem is most likely related to the other bugs filed on browser sluginess
with GIFs.

is there any point of keeping this bug open?
(Reporter)

Comment 6

16 years ago
This seems to be a lot better than it was previously.  The browser no longer
locks up as I try and scroll the image, but http://www.evil3d.net/news/ still
feels quite sluggish scrolling up and down with the slider bar (K6-3 400,
linux).  A lot slower than a typical fullscreen image on digitalblasphemy, for
example.

http://www.xsta.cc/mozilla/mesh.html is the updated testcase link.

A cursory search doesn't show any gif-related bugs that this seems to be a dupe
of.  So I'd like to keep it open until we can attach it to another bug.
Hampton: can you still reproduce it on 1.0RC1? it's even very fast for me on a
Cel. 433 lap with 0.9.9/Linux.

Comment 8

16 years ago
WFM in 1.0RC1 on KDE 2.2.2, X-Server 4.2.0.
Scrolls just fine... smoothly and responsively.

Machine: AMD 450 MHz, 256MB RAM
(Reporter)

Comment 9

16 years ago
Scrolling http://www.evil3d.net/news/ may still be a problem.  I tried RC1 on my
K6-3 machine and I was still having problems with that page.  With a 1.5 GHz
processor, it works fine.

I will test again tomorrow, just to make sure.  It could be a profile issue.
(Reporter)

Comment 10

16 years ago
This is much better with RC1, even on the slower machine.  I no longer see a
noticeable delay when switching tabs and scrolling the evil3d.net page is
considerably smoother (although not perfect).  Fine with me if we resolve this
bug now.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.