Some images get background-color lines/stripes when scrolled

VERIFIED FIXED in mozilla1.0



18 years ago
14 years ago


(Reporter: Peter, Assigned: pavlov)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt2 RTM] [ETA 06/27], URL)


(10 attachments, 2 obsolete attachments)



18 years ago
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9+) Gecko/20010529

Scrolling page with images (jpg) causes white lines in the images.

This bug may or may not be related to theother bugs on corrupted images (i
suggest to make it a dependency).

Try this link:

SPAM: Yes, those are some very cool Quake 3 wallpapers :)


18 years ago
Keywords: mozilla0.9.1

Comment 1

18 years ago
not seeing win98 2001052920

we do have a imagelib component..
wfm with win2k build 20010529.. (CVS opt)
Assignee: asa → pavlov
Component: Browser-General → ImageLib
QA Contact: doronr → tpreston

Comment 3

17 years ago
I'm definetely still seeing this on winNT, build 2001-05-30, voodoo3-3000,
1280x1024x64k colors, 228MB RAM

Comment 4

17 years ago
I can reproduce this as well. I am running Win2K (SP2 applied) using Mozilla
2001052904. My computer has video settings which are currently 1280x1024x32 bits
color (GeForce card) and I have 256MB system ram. If you go to,
you will notice two jpgs at the bottom of the page. Scrolling up and down will
cause the one on the left to display the problem, but the one on the right is
OK!!! There might be a clue here.

I thought maybe that the jpg's were encoded differently, but they both appear to
be v1.0, standard Huffman-encodeded files (as reported by Paint Shop Pro). One
thing that PSPro reports differentely between the two images is that the
misbehaving one reports "unknown" pixels per inch, whereas the behaving one
reports 100 pixels per inch. In other words, there appears to be at least a
slight file formatting difference. Perhaps this is related?

Comment 5

17 years ago
I see this under i386 Linux, build 2001060713.  Confirming, setting OS to All. 
Another URL where this occurs is  Go down to the one
labeled "More Lunar Wallpapers!".  Note that a lot of the other images don't
have problems.
Ever confirmed: true
OS: Windows NT → All


17 years ago
Target Milestone: --- → mozilla0.9.3

Comment 6

17 years ago
Another important thing to note:
The problem is not limited to JPG files! I have come across this problem with
GIF's as well. Using 2001060703 on Win2k.

The first dialog box gif on the page doesnt have the problem but the next two do.


17 years ago
Hardware: PC → All

Comment 7

17 years ago
*** Bug 86278 has been marked as a duplicate of this bug. ***


17 years ago
Summary: Scrolling page with images (jpg) causes white lines in the images. → Some images get background-color lines/stripes when scrolled

Comment 8

17 years ago
Same problem on

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010616
BuildID: 2001061606

Reproducible: Always
Steps to Reproduces
2.scroll down to see images (On the right hand side) with white lines
3.Mouse over the last image and you will notice all images refesh and
  most images are then displayed ok.

Note: It is mostly images built below the current display area that have this 

Comment 9

17 years ago
Bug 85804 shows PNG problems, as well.

Comment 10

17 years ago
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010618
BuildID: 2001061808

Has any one else noticed, that on some pages
you can also get a stripe, on _simple_ lines of text, 
usually the bottom or top, (I don't think I have seen it through the middle of
the text),  and scrolling up & down fixes the problem.

Comment 11

17 years ago
I have just been playing around, on:
1) right mouse clink and choose save image (but don't save the image)
2) move the same file box about, you will observer lots of white lines
3) cancel the save file
4) the white lines will remain
5) click on the image the image will refresh - the lines will disapear.

In, although the first page seems to be ok now,
there are mon examples on the headlines page (sci/tec etc) mouse over some of
the small story links beneath the pictures, on some you may see the line of text
refresh, so that the text is fully displayed. Mouse over the images they will
refresh and the lines will disapear.

My reading of this you don't have a problem with images as such, but with 
some sort of draw/refresh problem.

Comment 12

17 years ago
It looks to me like a "clipping" problem against the bottom edge of the window
in which the images etc are rendered. 1 row of pixels is sometimes not redrawn
as you scroll up and down, almost as if the clipping/refresh in conjunction with
the scroll is wonky. More PNG images which demonstrate this can be found at:

In particular if you look at one of the images, say MorphingFace2.png. Now
scroll up and down until this occurs, then get a screen capture of this image
(Alt-Prtsc on a Windows box). If you zoom in on this image you will notice that
it is always 1 row of pixels (I have never seen it wider than this) that is
affected. In addition, it does NOT affect the image border. Note these images
are drawn with a 1 pixel border via the following statement:

<td><img src="../Images/Data/MorphingFace2.png" border=1></td>

I am not familiar with the source/algorithms in Mozilla for doing this... but I
hope this information is useful in tracking it down.

By the way, using BuildID 2001061304 on Win2K.

Comment 13

17 years ago
I've been seeing this in a lot of places. Some things I've noticed:

1) If an image is repeated in another <IMG> tag, one might do it while the other
2) It only does it when you move it (or another window) up and down, not left
and right. Use the annonying pop-up ad at that quake site to show it.

I did some looking around, at it seems to only happen with images where the size
is given. Unless someone can find a counter example, I think we should invite
the fine folks from bug 74313 for a party.

Linux 2001062021

****. Now i'm getting it in the scroll bar of the Additional Comments box. I'm
thinking a new bug for that one.

Comment 14

17 years ago
linux 2001062021
It seems to me its a refresh problem.
As point (2) above says _ANY_ popup box draged overimages, showing this problem,
can cause the white lines.
On (2) above - it use to do it left and right as well, but now it appear, with
this build, only up and down.

(Back to (wolrd section), everthing looks ok today, unless
you look very  carefully and then you see the problem. If you use the pop-up box
and drag it around a bit you can make some images totally disappear. (click or
mouse over to make them reappear))


Comment 15

17 years ago
Updating kw to mozilla0.9.3 since mozilla0.9.1 is gone, and 0.9.2 is just around
the corner.

BTW, does anyone else think the component should be Compositor, since when you
click on the image, the problem goes away?
Keywords: mozilla0.9.1 → mozilla0.9.3
*** Bug 88632 has been marked as a duplicate of this bug. ***

Comment 17

17 years ago
*** Bug 89254 has been marked as a duplicate of this bug. ***

Comment 18

17 years ago
I see this behavior even on text, not only on images... When i slide the page up
slowly some horizontal white stripes appear sometimes. Not as often as within
images, but they are there, too.

I use the Mozilla 0.9.2 build 2001062823 under Linux.

Comment 19

17 years ago
I've got an additional comment...

I found out, that in the test-page at
only those images get the stripes which are not the biggest in that row of the
table, so only if they don't give the table their height...

Perhaps that helps??

Comment 20

17 years ago
*** Bug 89294 has been marked as a duplicate of this bug. ***

Comment 21

17 years ago
When I look at I get the
white lines also (horizontal)

Comment 22

17 years ago
I just fond a site where we have the problem just with vertical stripes, and
only when you move any other window across the screen. As it is not needed to be
a Mozilla-window it really seems to ba a refresh-bug. Just try yourself at:

Comment 23

17 years ago
I have the same problem with linux 2001061108 (e.g.: But when you click on the
image the lines disappear. After scrolling down (the image is no longer visible)
and scolling back the lines are also back.

Comment 24

17 years ago
Doesn't look like this is getting fixed before the freeze tomorrow night.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
*** Bug 92280 has been marked as a duplicate of this bug. ***

Comment 26

17 years ago
*** Bug 85062 has been marked as a duplicate of this bug. ***

Comment 27

17 years ago
*** Bug 85804 has been marked as a duplicate of this bug. ***

Comment 28

17 years ago
*** Bug 86695 has been marked as a duplicate of this bug. ***

Comment 29

17 years ago
bottom right image at gets easily corrupted with scrolling

Comment 30

17 years ago
Odd... `powered by linux' on 2001062823 does not get mis-displayed no matter
what I do. In fact, nothing on does.

Comment 31

17 years ago
The png test page at shows this 
bug. Check out the owl at bottom of page, also images to right and above owl. 
Other images are not effected.

Using CVS 8/13 on Win98

Comment 32

17 years ago
NONE of the images on that page show the bug for me.
Linux 2001081106
This will be hard to fix if everyone is seeing different stuff

Comment 33

17 years ago
I am running build 2001081504 under Windows 2000 at 1280x1024 x 32bit colors
(with Large fonts) and I am running it full screen. I can see the same effect in
a few of the images on the above page
( Specifically, on the 3
horizontal parrots and the Ice picture (kitty corner to the owl). You can do
this by scrolling it partially out of the window and back. Alternatively, you
can right click to bring up a context menu which partically occludes the picture
and when you dismiss the menu the lines at the dialog edge will appear. I have
been able to consistently produce this for months. It happens very frequently
for me. 
I wonder if the screen resolution is an issue... perhaps there is some rounding
error in calculating clipping regions as a function of window size and picture

I didn't think I could reproduce this anymore (fizzilla build) because I haven't
seen it in a while but I just found I can by making the window very tall and
skinny (like smaller than the owl is wide) and shaking the horizontal slider
back and forth violently for a while.  The lines do appear eventually.

Comment 35

17 years ago
We need to track who is seeing what. I see those parrots page perfectly, so for
now i am asumming that linux users can see png fine, and have problems with jpg
and gif, while the problem in windows seems to go the other way around.

However, my original testcase was, the fox image on the bottom right.
This is fixed now. Maybe the removal of the old imagelib code fixed this.

Comment 36

17 years ago
To summarize by image type and web page, here is what I see on Windows 2000 with
2001081504 (1280x1024x32bits color):

1) - This contains a bunch
of JPG files (quake 3 images), many of which (but not all) show the problem!

2) - This shows a bunch
of PNG files which manifest this problem (scroll down to the Bezier surface
section and below). In fact, every images except 1 (portals5.png) have this
problem for me. 
3) -- This one is harder for me to reproduce. This page
displays a big GIF file (map of Germany). By default I cannot get the lines to
display when I have my browser window maximized. However, if I resize my browser
window to 913x810 and then right click to bring up the context menu in the
middle of the image and dismiss it. I can get the vertical lines to appear.
Whereas if I Resize to 680x548 the lines go away again. This is why I postulated
above that it might be some kind of roundoff problem in the clipping routines
that is a function of window size and image size. If someone could point me
where to look in the source for this I might be able to track it down. 

I have seen it on other GIFs as well. Unfortunately my posted source for GIF's
(see entry above) at
has been moved.

Hope this is helpful. 

Comment 37

17 years ago
Hmmm. ALL those webpages are working fine in linux 2001081514, which leads me to
think that this bug has become windows only.
Can another linux user confirm this? Using 1024x768x16
The fizzilla build doesn't run on Windows. :)  

(Mac OS X)

Comment 39

17 years ago
I can confirm the problem in Linux 4.06/X4.1/KDE 2.1.1 1600x1200x16 on, but 
not the other two. I originally created a bug that described the
problem with emoticons in the mail reader.  That bug was marked a 
duplicate of this one.  Maybe the problem shows up easier using 
small graphics.

Comment 40

17 years ago
You forgot to post your build number. 

Comment 41

17 years ago
Sorry about the build.  I built a CVS version 8/13/01.  I guess its a little
dated. ;)

Comment 42

17 years ago
Please get a new build asap and report back on all pages tested here., please get a build of the 18th or up. I havent checked if
your build is a "branch" build, if it is, then the old imagelib removal wasn't
done in that day, it was done the 17th i think.

Comment 43

17 years ago
I am now running Build 2001082008 (trunk) on Win2K at 1280x1024x32bit and I get
the exact same results as I reported yesterday (on 2001-08-20 13:42).
Specifically, I see the same problems with the following pages for JPG, PNG, and
GIF files:

2) - 

See instructions in my previous post for further comments on each page.



17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 44

17 years ago
I am still getting the horizontal lines on a Linux CVS build that just finished
a few minutes ago.
I retested

Comment 45

17 years ago
*** Bug 84994 has been marked as a duplicate of this bug. ***

Comment 46

17 years ago
Further clue:
Using the page from, I
had previously noticed that there was 1 image on this page which did not get the
lines during scrolling (namely portals5.png).  Perusing the page source and the
images. The images seem to be all sized to 320x240 and embedded in tables where
the size is given as 320x240...EXCEPT for portals5.png. This image is sized at
319x240 but the table definition in the source  which is given as:
<td><img src="../Images/Data/Portals5.png" width=320 height=240 alt="portals 5"

I made a local copy, resized the image to 320x240 and voila it was now behaving
like the other images and manifesting the same scroll line issues.

This may lend credence to my previous hypothesis that there is something related
to sizing of  images; perhaps roundoff errors in the windows expose/clipping
area sizes when other objects occlude an image.

On a related  note... doesnt everyone see this? This is the one thing in Mozilla
the consistently drives me nuts! 

Comment 47

17 years ago
Although I have reported in the past seen as haven seen this problem quite often.
I can nolonger reproduce this on a modern build on either linux 
or windows 2000 (my current windows build is 2001020110 and my linux build 
is even more recent). Maybe you could/should try to retest on a new build and
post your results.

Comment 48

17 years ago
Darn... I forgot to mention in my comment from yesterday that I am using build
2001082703 (trunk) and running under Windows 2000 (sp2 applied) at 1280 x
1024x32bit. I still see these problems quite regularly. this is now 3 days old. 

Comment 49

17 years ago
What happens when you put your resolution to 1024x768x16?
Try also resizing your browser window.


17 years ago
Target Milestone: mozilla0.9.5 → Future

Comment 50

17 years ago
Eureka- The font size is the variable!  Using Build 2001082703 (trunk): -

First I verified that changing to 1024x768x16bit behaved exactly the same
(namely it was still problematic). 
Next I changed from Large fonts (120dpi) which all my previous tests and reports
used, to Small Fonts (96dpi) and retested! 
At both 1024x768x16bit with small fonts AND 1280x1024x32bit with small fonts,
ALL the test cases were OK! 

No wonder, it hasnt been as widely reported as I would have suspected... it
seems to mostly manifest itself (under win2K on my system) using Large fonts!
That wouldn't affect the MacOS and Linux users reporting the same problem, though.

FWIW, this is the one bug that prevents me from using Mozilla in public
(presentations,kisoks,etc.).  I use it for checking my own authoring, and when
someone's in my office looking at a proof and the images break up they always
say, "what the heck kind of crappy browser is that?"  I just slap 'em but it
seems strange to future this since it's SO visible.

Comment 52

17 years ago
I cannt believe this one is now marked FUTURE either! As I mentioned, I use
Large fonts on Win2K and I see this very often and it is VERY in your face.

Another GIF example that shows this is at (Build 2001082703):

The dialog box at the top of the page. 

I certainly think this target milestone needs moving up... how does that get done?

Comment 53

17 years ago , please report about your system as much as you can,
distribution, kernel, window manager, Xfree86 version, xfs usage, current X
server dpi configure, everything you can.
I am using mandrake 8 with kernel 2.4.9, Xfree 4.1.0, kde 2.2, using 75dpi
fonts, and making mozilla use fonts at either system setting or also 96dpi
Since around the 15th i can no longer reproduce this

Any other linux user having this problem?

Comment 54

17 years ago
I am using linuxfromscratch as a distribution--In other words I roll my own.
I'm using Linux 2.4.6, X4.1 (no xfs), KDE 2.1.1, 1600x1200x16, 100 dpi.  I use
gcc and havn't been able to make a new Mozilla for a while due to a
build problem.  I'll try again tonight.

Comment 55

17 years ago
A fresh build from cvs (2001090111) still has the problem in Linux.

Comment 56

17 years ago
*** Bug 93744 has been marked as a duplicate of this bug. ***

Comment 57

17 years ago
I'm getting this problem quite often on Linux. I'm using Moz 0.9.4. An example
page is Here the two elephants get white lines across
them. Using RedHat 7.1 with XFree86-4.0.3, Kernel 2.4.3, Sawfish, Gnome Desktop,
xfs is being used as a server, I'm using a truetype font in moz (Arial, 14pt),
Xfree86 resolution is set as 100x100 dpi.

From xdpyinfo:
screen #0:
  dimensions:    1280x1024 pixels (325x260 millimeters)
  resolution:    100x100 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0x31
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store NO, save-unders NO
  largest cursor:    64x64
I'll try and attach a screenshot.

Comment 58

17 years ago
Created attachment 49577 [details]
Screenshot demonstrating problem (24bit display on Matrox G400)

Comment 59

17 years ago
I see this problem both on OS/2 and Linux with Mozilla 0.9.4 ("Mozilla/5.0
(OS/2; U; Warp 4.5; en-US; rv:0.9.4) Gecko/20010918" and "Mozilla/5.0 (X11; U;
Linux i686; en-US; rv0.9.4) Gecko/20010913" respectively from the about: page).
I note that the number and spacing of the lines is influenced by the speed with
which I scroll the page. Yet another example of the bug:; note that the _A Knight's Tale_ "poster"
image does _not_ have the problem, but the image directly below it _does_.

Comment 60

17 years ago
*** Bug 101538 has been marked as a duplicate of this bug. ***

Comment 61

17 years ago
this is a VERY visible bug and should be fixed before 0.9.5. 

Comment 62

17 years ago
11 duplicates, 18 votes.

Comment 63

17 years ago
mostfreq isn't any more
( Have a look at )

May this bug affect the "V" in combo boxes, too ? (->screenshot)
I see this random effect if I scroll up any Bugzilla page.
Keywords: mozilla0.9.3 → mozilla0.9.6

Comment 64

17 years ago
Created attachment 51719 [details]
Scrolling has bad effect on form elements' images

Comment 65

17 years ago
For me, this regressed between

I.e. it works in Sept 04 build, this bug reappears in Sept 05 build.
The only checkin that I could see related to this would be dbaron's wrt the
browser.display.screen_resolution preference. (bug 69205)

I commented out the line setting my screen_resolution to 80 (which is correct
for me), then mozilla took the dpi value from X (which is also set to 80).  I
still had the bug.  So then, I went into Preferences->Appearance->Fonts and
changed my screen resolution to 96 dpi.  I then went back to my testcase
( and tested it out.  Success!  I no longer
see this bug!  Change the setting back to "System setting", restart Mozilla, and
I see the bug again.

Can others confirm my findings?  (I.e. that this problem is dependent on the dpi.)


BTW, I'm running XFree (Debian/unstable) ATI Mach64 1024x768x24bppx85Hz
on a 17" monitor.

Comment 66

17 years ago
dbaron: can you please take a look, if you caused this regression?
I set my Mozilla to 84 dpi using that clever little calibrator and now I'm
getting scrolling artifacts in *text*.  Just <h2> enclosed strings!  I think
you're on to something here.  

I haven't seen the striped images yet, but perhaps that's just a side-effect of
a scrolling bug.

fizzilla 2001091313.

Comment 68

17 years ago
Back on 8-31-2001 I made similar comments for Windows 2000. Specifically, I
noticed at that time, that when I changed font sizes (from large font to small
fonts) on my OS the problems went away. This is still the case wotj 2001092803.

In my case, at 1280x1024x32 bits and large fonts - 120DPI - p2t = 15.0
at 1280x1024x32 bits and small fonts - 96dpi = p2t = 12.0.

In the layout code there seems to be many dependencies on the pixels-to-twips
(i.e. p2t) for sizing calculations. It would be interesting for the Linux
problems to know what the p2t values are for the working and non-working cases,
to see if their is some correlation.
> dbaron: can you please take a look, if you caused this regression?

This could perhaps be a rounding issue related to cases where p2t is not an
integer, or something like that, except we always round it to ensure that it is
an integer (bug 16200).  I wouldn't be surprised if it's something that shows up
only at some logical resolutions, so I suspect making the DPI setting work could
have caused it to "regress", but I wouldn't really call that a regression from
my change since it would have been broken with those DPI settings before my
change.  (This is assuming it actually was my change that caused it to start
Still, if this were the same as bug 16200, it would:
 * never show up on the GTK port (Linux)
 * only show up at resolutions that are not integral divisors of 1440 (such as
60, 72, 80, 90, 96, 120, 144, 160 dpi)

Comment 71

17 years ago
dbaron: I just read the report for bug 16200, and I do not think this one is the
same one either. However, I do think it is another in the category of bug 63336. 

The reason is that while scrolling is a factor, I find general expose/clipping
redraws of images cause the same results. For example, on Windows, right click
on a problem image to bring up the context menu so as to partially occlude the
image  and then dismiss it. It will display the line artifact either
horizontally or vertically (or both) in line with the edge of the context pop up
menu dialog. 

Also, my comment from 2001-08-29 seems to show something related to Image
redrawing that is image specific. On that web page, you have two specific images
side by side, scroll through them, one gets the horizontal lines and the other
doesn't (their declared image sizes are 1 pixel different). 
Could anyone who is seeing this please try the patch in bug 104544?

Comment 73

17 years ago
*** Bug 95824 has been marked as a duplicate of this bug. ***

Comment 74

17 years ago
*** Bug 100708 has been marked as a duplicate of this bug. ***

Comment 75

17 years ago
*** Bug 103714 has been marked as a duplicate of this bug. ***

Comment 76

17 years ago
Patch in bug 104544 works for me (at least on one page I've tested).

Comment 77

17 years ago
I'm running 0.9.5 on Win98 and have seen this for since maybe 0.9.1?  I can't
remember.  Following advice, I looked at Mozilla's font display resolution
(Preferences -> Appearance -> Fonts -> Display Res).  It was already 96 dpi;
changing to 72 dpi or back to 96 dpi didn't eliminate the problem.  Looking at
other comments for this bug, I changed Windows' fonts from Large (120 dpi),
which I have used for a while, to Small (96 dpi).  This has eliminated the
lines, whether Moz uses 72 or 96 dpi display resolution.

Comment 78

17 years ago
To: Bryan Ryner:
Yahooo! The patch from bug 104544 fixes the problem for me! Here are the details:
I have been experiencing this problem regularly since at least 2001052904 on
Windows 2000 at 1280x1024x32 using Large Fonts. First, I verified that the
problem still existed in 0.9.5. Next, I downloaded the latest tarball, built it
and confirmed that the problem still existed. Finally, I appled the patch,
rebuilt and confirmed that the problem disappeared!  I tested on numerous sites
on which I can reliably reproduce the problem.

I say lets get it approved and checked in to tbe builds ASAP.

Comment 79

17 years ago
As described earlier I had that problem under Linux, too. Now I was using Mozila
0.9.5 and the XFree-Server version 4.0 with the module 'nvidia' ver.1.0.4 at an
resolution of 1152x864. The problems appeared at 75, 96 dpi and system setting.
Now I am using an GeForce2 MX instead of the old TNT and had to update the
X-Server to 4.0.2 using the module 'nvidia' ver.1.0.1541. Now all the problems
disappeared at all dpi-settings and at the same resolution and the same
'unpatched' Mozilla 0.9.5!

So this bug seems to depend on the X-Server, too....

Comment 80

17 years ago
For what its worth, scrolling slowly makes this problem much worse,
while scrolling quickyly can almost eliminate it. 
I rarely see this when using PgUp/PgDown to scroll.
Also, switching to another tab and then switching back seems to clean
up all the images for me.
I'm running moz 2001101201, X 4.0.1 with the Nvidia 1251 drivers
under RH 7.0

Comment 81

17 years ago
*** Bug 104198 has been marked as a duplicate of this bug. ***
My system is Windows2000(SP2) with GeForceMX Videochip.
But my system don't reproduce this bug.
Bugzilla-jp is reported same problem.
This bug reporter said,When vertical scrolled webpage with Windows Media Player
over the Mozilla Window ,this bug don't reproduce a pile of media player.
When this bug reproduced,Invalid Area is Rectangle Only?

Comment 83

17 years ago
*** Bug 110687 has been marked as a duplicate of this bug. ***

Comment 84

17 years ago
My XFree dpi is 100x100. Changing Mozilla's pref to read 96dpi fixed this
problem for me.

Comment 85

17 years ago
This fix:

Fixed some image striping issues with odd DPIs.

Can we see if this was fixed?

Comment 86

17 years ago
Regarding comment #85 from Michael Kaply, it still is a problem for me at 72 dpi
nightly build 2001111908. I can also confirm that after changing to 96dpi the

Comment 87

17 years ago
*** Bug 111215 has been marked as a duplicate of this bug. ***
This Screenshot is Mediaplayer window over Mozilla.

Invalid area isn't rectangle,this case.

And this site has no table,but 0.9.6 reprodeced.

Comment 89

17 years ago
*** Bug 111708 has been marked as a duplicate of this bug. ***

Comment 90

17 years ago
*** Bug 111792 has been marked as a duplicate of this bug. ***

Comment 91

17 years ago
*** Bug 111888 has been marked as a duplicate of this bug. ***

Comment 92

17 years ago
Another data point: Mozilla 0.9.6 (2001112012).
Mozilla dpi set to system setting; system setting according to xdpyinfo is:

screen #0:
  dimensions:    1280x1024 pixels (361x271 millimeters)
  resolution:    90x96 dots per inch

XFree is from Debian Woody, and is a CVS snapshot. Debian version is 4.1.0-9;
XFree86 -version prints:
XFree86 Version / X Window System
(protocol Version 11, revision 0, vendor release 6510)
Release Date: xx August 2001

This image is the first one in a while I've seen this with. The URL (hope it
works for you, too...) is
<>. This is when
displayed on the "Electronics > Categories > Computer Add-Ons >
Drives & Storage page" (no URL, sorry: They have session id in them).

Comment 93

17 years ago
Happening a lot less often now, but I still see this on certain specific images,

Example: the second to last image at:
(image of red and yellow chao on beach, JPEG)

Comment 94

17 years ago
I reported earlier that I don't have this problem anymore with my new X-Server.
But that is not true, I forgot restarting the mozilla after changing the
dpi-setting. The problem does not occur with the tested 96dpi, 93dpi and 75dpi,
but does occur with 92dpi and 72dpi. This are the only values I have tested with
the actual mozilla 0.9.6.

Based on the last posted URL I have generated a simple testcase which shows the
error with GIFs and JPGs and how to turn on and off the wrong repainting with
bold and italic text. All tested GIFs and JPGs did work, I just took one of
each. The inserted <br>s don't change anything but the appeareance, they could
be <p>s or nothing, too.
But look yourself at:

Comment 95

17 years ago
Ah... good test case! My DPI is 80x80, I see it on Thomas' page, on images as
well as some of the text. Perhaps /even/ dpi's trigger the rounding error, and
/odd/ dpi's don't? (default is 75x75 I believe, so most people wouldn't see it).

Comment 96

17 years ago
Using 75x75 in the x server and 96 dpi in mozilla makes me never see this bug

I think we should relnote this

Comment 97

17 years ago
I've had this problem since 0.9.3 and I'm getting very frustrated with it. I'm
not sure what I can do that'd be useful, but I'm running the latest drivers from
nVidia under Linux with a Riva TNT at 92 DPI.
Deraj, have you tried setting your DPI to 91 or 93 to see if that makes the
problem go away?

Comment 99

17 years ago
This bug is still alive and kicking. I think the previous comments and
investigations show that it is related to roundoff (twips to pixels) in the
code, not to video drivers. Refer to bug 63336 for a general item covering these
issues. It is also not just on Linux.

I still see this problem in 0.9.6 under Windows 2000 at 1280x1024x32bit (120
dpi, which corresponds to a pixels-to-twips ratio = 15.0)

The best example webpage to demonstrate it is:

Every image on this page displays this phenonmenon on my computer when scrolling.

Comment 100

17 years ago
seeing this at using 0.9.6 on NT 4.0,
large fonts, 1280x1024x16 with a Number Nine SR9.  In color
prefs I have use system color and use my colors checked and
have a color scheme with a dark background (
, although the High Contrast Black color scheme that comes
with NT works just as well).

Happens with the first two and the last circular .GIFs on the
page.  Interestingly (of diagnostic significance?) it only
happens with the top part of the first two such GIFs.

As commented before, this has been around for awhile and
scrolling slower makes it worse.  Using a dark background
color scheme can make it more easily apparent.

Comment 101

17 years ago
With 0.9.6 on Win98 I see stripes at 98, 99, 116, 118, 120 and 125 dpi.
I see no stripes at 96, 97, 100, 119 and 121 dpi.

Comment 102

17 years ago
This problem with the horizontal lines through the images happens for me under
Linux (Radeon, Debian "testing" XF86 4.1.0-7, 1600x1200x24, 100dpi) but not
under win2k.  It seems to happen more on pages with a lot of images (such as
).  Actually on that page it happens as soon as the page loads, before any
scrolling is done.  

Using 0.9.6 on both platforms.

Actually I just changed the DPI setting in the Font preferences to 96 instead of
"use system setting" and it went away.  Hopefully this will help track down the
root of this bug.

Wait, this bug has not been assigned to anyone and is still "NEW" after six
months?  Cripes.

Comment 103

17 years ago
Update: It mysteriously re-appeared for me despite altering the dpi setting, and
also happens with form buttons.  

Apparently I can't read either, I see someone is working on this after all,
sorry Stuart. :-)

Comment 104

17 years ago
here's another funky, twisted datapoint:

a Google cache copy of a page ( ) shows
stripes, although the original page does not (I asked for
and poked the cache link, which was
at the time I did this)

Wonder what that's all about. . .  Anyway, my config's at

OBTW, I tried
(mentioned in )
at a number of different DPIs and none of 'em striped for me. 

Comment 105

17 years ago
This only happens to me scrolling down. If I scroll down past an image, and then
back up it looks fine.

Comment 106

17 years ago
Yes, that is the whole point. I occurs when the during scrolling if part of the
image gets clipped against the edge of the window. Then when it repaints it
there is a 1-pixel line. Hence, if you scroll using the Page Up/Page Down keys
or by clicking the scrollbar between the thumb and arrows, you might not even
see it because it scrolls 1 page at a time (and the odds of clipping an image
are lower). Scrolling by clicking the scroll up/down arrows or by dragging the
"thumb" increases the odds dramatically... but you still have to have the right
conditions for this to happen (Pixel-to-twip ratio, image size, etc). 

I can also get this to occur by have some other object (like a pop-up context
menu) partially clip the image... when it is redrawn, there is a horizontal line.

As I have said before, for my computer setup, the single best site to
demonstrate this is Go there and
scroll down as described above and voila.

Comment 107

17 years ago
hmmmm. works fine for
me.  And I get the stripes on scrolling in both
directions, not just scrolling down.  And the images involved have 0
border width.  Perhaps this is not one bug, but a set of related bugs(???).

Comment 108

17 years ago
*** Bug 104374 has been marked as a duplicate of this bug. ***

Comment 109

17 years ago
I dont see it at however, I have my Browser window maximized
(1280x1024) so I can't really scroll down over the images. You must either have
a smaller screen resolution or your browser is not maximized. Is this the case?
If it is the latter, then you may not see the problems because it is definitely
a function of browser screen size. I found that I could re-size my windows on a
given problem page (to some magical size where I think the pixel roundoff issues
dont occur for the given images) and the problems would disappear.

Comment 110

17 years ago
of course you dont see it when you resize the window. when you page down or
page up to display the image, it doesnt render the image in slices as when
cursoring or using the slider bar to show progressively more of the image. there
must be some off by one mathematical error or the like thats not including that
row of pixels in the redrawing.

btw, i can exhibit this problem at home sometimes on my moz 0.9.3 and here at
work on 0.9.2 (really I should be using 0.9.6 at both locations) but even with
these  versions that I originally reported the bug on, I do not see any
excercizing of the bug on the pages.

its been a month or so since I've seen it again actually, come to think of it.


Comment 111

17 years ago
When I refered to re-sizing: I meant I could resize the window so that
subsequent scroll operations would or would not affect things. I agree it is a
pixel round off issue. I have been saying so for months.

I will attach a part of what I see when I scroll at when running Build 2001121003 on
Win2K at 1280x1024x32bit.

Comment 112

17 years ago
Created attachment 61496 [details]
Screenshot of  WildMagic site showing stripes

This is what I see when I scroll at

Comment 113

17 years ago
Just for the record - we had a very similar problem with SVG, see bug 114854. 
It seems to be a rounding thing when converting from twips to pixels. Our 
solution is to inflate the dirty-rect passed to nsIFrame::Paint() by ~1/2pixel.

Comment 114

17 years ago
Inflating the output rect by 1 pixel works for me
(Win98, 120 dpi and 96 dpi)
Please check other platforms.

I did not manage to create an attachment
("You did not specify a file to attach", but I did)
so here is the patch:

RCS file: /cvsroot/mozilla/gfx/src/nsRenderingContextImpl.cpp,v
retrieving revision 3.25
diff -u -r3.25 nsRenderingContextImpl.cpp
--- nsRenderingContextImpl.cpp  2001/12/12 01:35:21     3.25
+++ nsRenderingContextImpl.cpp  2001/12/22 12:30:07
@@ -895,6 +895,10 @@
   sr.y = aSrcRect->y;
   mTranMatrix->TransformNoXLateCoord(&sr.x, &sr.y);

+  -- pt.x;
+  -- pt.y;
+  sr.Inflate (1, 1);
   nsCOMPtr<gfxIImageFrame> iframe;
   if (!iframe) return NS_ERROR_FAILURE;

Comment 115

17 years ago
Mozilla 0.9.7 Talkback build id 2001122106 
(binary download) for Windows 98

A gif with a transparent background is redrawn as a number of
separate pieces.

A gif with a white (non-transparent) background is redrawn correctly.

You can see one example of the problem at
(Half of the images break up)

and another at
(Logo in upper left breaks up).

This seems to be a problem involving repainting the window,
since the broken image is restored to its correct appearance
by a single mouse click
or by bringing a different browser tab or a different window
to the foreground and then returning the html page to the foreground.

Comment 116

17 years ago
Daniel: I think you're wrong, it has nothing to do with transparency. In your
first example, everything in the month of Febuary is bad, but the other images
are fine. 

Comment 117

17 years ago
Bottom two scenes (4 images) at
exibit this behavior too. No other images on the page do. I thought gfx2 was
supposed to eliminate "twips". 35 votes... might be nice for 1.0.
Keywords: mozilla0.9.6 → mozilla1.0
Created attachment 63396 [details]
dropped line on scroll in text on OSX

I hadn't noticed any white lines on OSX for quite a while, even after switching
to an odd DPI, but I just found in a text block that while it's not drawing a
white line, it does appear to be just not drawing the line at all.  This is
clearly visible in the text sample comparison attached.  The erroneous render
was found as I scrolled down with the arrow keys. After snapshotting it I
scrolled away and back and it was rendered properly.  I have not seeing the
problem with an even DPI.

Comment 119

17 years ago
Yes, I have the same problem as #118 quite a bit of the time. The bug only
occurs for me (Linux) when scrolling down. Scrolling up always renders properly.
I'm betting this is a related bug, but a different bug, nonetheless. It's also
very annoying =(

Comment 120

17 years ago
Created attachment 63785 [details] [diff] [review]
patch to inflate the dirty rect by one pixel if possible

This patch could be a workaround for the problem.
The dirty rect in inflated by one pixel, if possible.
Works for me under Win98.
What do you think?
I didnt noticed this bug until I upgraded from mozilla 0.9.5 to 0.9.7. My system
is RedHat 7.2 i686.

Comment 122

17 years ago
Merging with bug 116496.
Severity: normal → critical
Keywords: nsbeta1, nsdogfood
Target Milestone: Future → ---

Comment 123

17 years ago
*** Bug 116496 has been marked as a duplicate of this bug. ***

Comment 124

17 years ago
Created attachment 66804 [details]
Example of artifacts caused by scrolling the test URL


17 years ago
Keywords: mozilla0.9.9
*** Bug 104544 has been marked as a duplicate of this bug. ***

Comment 126

17 years ago
This bug appears on Windows XP (currently running mozilla build 2002013103)

Aparently the images are only being partly redrawn untill you click in the
address box and it becomes redrawn correctly.

A related bug (in which the screen isn't drawn correctly till the address box is
clicked on) happens with , click on any
of the buttons, and notice how only part of the screen is updated, then click in
the address box and suddenly it's redrawn correctly. See bug

Comment 127

17 years ago
I still experience this in 0.9.8 (on Win2000) at 1280x1024 using Large fonts.
The latest test URL (
works fine for me, but I still experience problems at
and a variety of other sites. I have not tried applying the pixel inflation code
recently suggested. Does this work for others? Does it break something else, or
is there a reason it has not been accepted?
Created attachment 68202 [details] [diff] [review]
ugly patch to fix some rounding errors

I have investigated this problem a bit. The problem seems in the interal
storage using floats in gfx/src/nsTransform2D.cpp. Float's have limited
precision, which can cause rounding errors. Attached is a patch that when
rounding, first rounds to 0.01, and after that to int's. This is not a nice
solution, but for me it seems to work. 
I think this rounding error can alse be the cause of other pixel-offset
problems I am seeing sometimes (like the text moving one pixel to the right)

Comment 129

17 years ago
I get white stripes not only on images but also on text. Before it was mostly
images but with 0.9.8 it seems to be more often on text. The images where bad
but not so important, on text it is terrible since you can't read it sometimes.

I don't know if it is the same bug, but it comes when I scroll and looks the same.


17 years ago
Target Milestone: --- → Future

Comment 130

17 years ago
One page where I allways get broken textlines when scrolling up is

But it happens on a lot of places. I saw that people have reported this before.
I've seen it before as well, but it seems to be triggered much more often with
0.9.8 then previous versions I have run (all 0.9.x).

When you have a small font and the lines are gone the text becomes unredable. I
think this is a very important bug.

There seems to be a difference between the text bug and the image bug. In the
images there are empty (white) lines. With text the line is gone and the height
is decreased.

It might even be different bugs.

Comment 131

17 years ago
In reference to comment #128 - if you really think it's a nsTransform2D bug, you
may want to take a look at bug 97861...

Comment 132

17 years ago
Michiel: i tried your patch, but it does not work for me.
I use Win98 with 'large fonts' (120 dpi).

Comment 133

17 years ago
Sorry, i must be more exact:
The rounding patch solves the lines problem on many pages for me,
but not on all.
I still see lines e.g. on
(bottom two pictures).
MArtin: You colud try to lower the 100.0f's in the patch. They are quite
arbitrary. Try to change them in 50, or even 10. But this can introduce some
other errors.

Comment 135

17 years ago
*** Bug 126015 has been marked as a duplicate of this bug. ***


17 years ago
Blocks: 92997

Comment 136

17 years ago
per adt, critical for nsbeta1. hence plus.
Keywords: nsbeta1 → nsbeta1+

Comment 137

17 years ago
per adt, critical for nsbeta1. hence plus.
Whiteboard: [adt2]

Comment 138

17 years ago
Maybe you don't need more test cases, but on cvs-diff listnings from ViewCVS like

I see lots, and lots of white stripes on the colored parts of the table.
*** Bug 130084 has been marked as a duplicate of this bug. ***
*** Bug 129400 has been marked as a duplicate of this bug. ***

Comment 141

17 years ago
me again (config at ,
but I'm running 0.9.8 now).

With 0.9.7 and 0.9.8, I've seen stripes at this site:

with the interesting feature that images in the same row of a table may
exhibit differing behavior.   Sometimes it's all the images in the row,
none, one to the left, one to the right, one in the middle.

Perhaps this might be of some value to someone trying to debug this.
Perhaps not.

Comment 142

17 years ago
(pardon the two comments in rapid succession, but)
I think I finally found a useful bit of information -

    rescaled/resized images scroll fine

    images in their original pixel size get stripes

reported this, too, but

provides lots of positive and negative examples and 1 or 2
exceptions (MASQUE.JPG has no stripes and PARIS.GIF is such
a sparse image I can't tell one way or the other).  There's
also an animated .GIF (star.gif) that doesn't seem to stripe.

One image (lit.gif) appears twice on the page - once near the
top resized (no stripes) and once near the bottom in its 
native size (with stripes).

I'm attaching a text file with a line for each of the img tags
on the page.  They're preceded by a YES or NO (for whether or
not I see stripes) and the native pixel width and height of the
image (as reported on Mozilla's title bar when I view the image
by itself).

Comment 143

17 years ago
Created attachment 73563 [details]
list of img tags, native image size and whether I see stripes

attachment belongs to

Comment 144

17 years ago
Could you integrate all that into one HTML page, so that it could be easily
referenced for testing?

Comment 145

17 years ago
> Could you integrate all that into one HTML page, so that it could be easily
> referenced for testing?

     Great question.  I thought it would be great to have something more
compact and focused than

but with the same basic characteristics.  So I made a small table with
resized and non-resized images side by side, using images culled from  And it failed to exhibit the problem.  So, although

definitely captures some interesting aspects of the problem, it ain't
the whole enchilada.

     Perhaps someone more versed in in HTML than I (I've barely touched the
stuff) who can also see this problem at homeniscience could take a quick
stab at capturing its essence.  Maybe something will catch your eye that
didn't catch mine.

Comment 146

17 years ago
Robert - what DPI (or Pixels-to-twips) settings does your setup correspond to?

I can't see your stripes and you can't see mine (comment #112, and comment #99
for my settings). Also, I am running with my browser window maximized.

One thing I did notice on your example page
( is that I can muck up
certain images by popping up a context menu in front and then clearing it.
Mas1.jpg, Mas2.jpg, and Mas3.jpg (last 3 big pictures near bottom of page) get
screwed up royally. 

Simply right click on one of these images, the context menu comes up, and then
left click outside of box to clear the menu. The refresh of the images under the
context menu is screwed up. Jopizza.jpg will also get vertical stripes when I do
this, but all the rest are fine!

Comment 147

17 years ago
my font prefs report 96dpi (I remember experimenting with this (#c104)
before to no avail).  Current window size is 1007x637, although this
shifts somewhat over time (and doesn't appear to be critical to reproducing
the problem, as long as there's a need to scroll)
Rest of config at #c100

I see a context menu glitch, too, but not as serious as yours.  Specifically,
when I bring up a context menu and cancel it, it clears the stripes underneath
where the menu was and leaves a background-color stripe where the top of the
menu was.  On some images, it also leaves a stripe where the left hand side of
the menu was.

I have also seen pages where text or images are shifted laterally by one pixel
at the point where they scroll into view.

Comment 148

17 years ago
Robert - When I refer to DPI settings, I mean at the OS level not the Mozilla
Font size preferences. Under Win2K, you can see this by right clicking on the
desktop and getting the Properties->Settings->Advanced->Font Size. 

On my computer, when these settings are at 120dpi (i.e Large fonts) I can see
the problems I reported for the web page at
When I switch to 96 dpi (small fonts) and view the same page it renders
absolutely perfectly. 

For completeness, I also regularly see lines of text getting mucked up when
clipped against the edge of the window during scrolling.

Comment 149

17 years ago
Ok, I can duplicate this bug if i use large fonts.  There is a rounding error 
somewhere in either the transform code or in nsRenderingContextImpl::DrawImage 
itself, but I can't find it.


17 years ago
Target Milestone: Future → mozilla1.0

Comment 150

17 years ago
Created attachment 74489 [details] [diff] [review]
avoid the rounding errors

Here is a fix that avoids the double rounding in the transform code to avoid
the rounding of y to 1 for the dest pt.  I have tested this at 120dpi on
WildMagic's site.
Attachment #63785 - Attachment is obsolete: true
Attachment #68202 - Attachment is obsolete: true

Comment 151

17 years ago
Good sleuthing, pavlov. Not sure if the stuff under gfx/ is only for image
rendering... does this have a chance to fix the font rendering issues too? That
one's far worse, although interesting in action. Did you know if you take an
'o', and round away the last column of pixels, it becomes a 'c'? 'i' and 'l'
round themselves to nothing. I'm guessing not as many people see that one or it
would have gotten a lot more attention a long time ago. I lose a letter or two
on most pages. I'm running at 81x81 dpi, fwiw.

Comment 152

17 years ago
Comment on attachment 74489 [details] [diff] [review]
avoid the rounding errors

r=gagan ignoring the nsTranform2D.cpp patch
Attachment #74489 - Flags: review+

Comment 153

17 years ago
please ignore the nsTransform2D part of the patch.  that was a typo when looking
at the file.

Comment 154

17 years ago
I applied the patch and rebuilt the source on my local machine running Win2000.
This patch appears to fix the problems for me. I tried it on 4 known,
repeatable, problem sites for me and it worked. 

This really is good news! Thanks.

Comment 155

17 years ago
I went back to 0.9.8 and replaced gkgfx.dll with a patched one kindly
supplied by and the stripes at

went away.  Also, 1 pixel mid-character sideways shift that I'd noticed
recently when scrolling

also went away.
Since there are lots of other 120 DPI people around in this bug, could you all 

referenced in bug

And see if you get the white vertical lines here? Not image related, but 
definitely DPI related.

Comments go to that bug. Thanks.


Comment 157

17 years ago
Curious. See also my bug 119824 and bug 88485, which could be related to this.

Comment 158

17 years ago
*** Bug 132930 has been marked as a duplicate of this bug. ***

Comment 159

17 years ago
I don't think Bug 132930 us a duplicate of this as it is a single line actual
moving through the image while you watch.

Comment 160

17 years ago
I spoke too soon - while the stripes-on-scrolling bug definitely seems to
be fixed by the patch (I double checked) the lateral shift bug is not -
it just doesn't happen to me consistently on the first scroll, the way that
the stripes-on-scrolling bug does.  So when I went back to  and

and scrolled back and forth a few times, I was able to see the lateral shift
described in

(BTW, I didn't see any problem at

with or without the patch and DID see the problem described in

even with the patch.  In fact, it was so mesmerizing to see the background
color stripes flicker down the image that I reloaded it several times just
to see the show:-)
Comment on attachment 74489 [details] [diff] [review]
avoid the rounding errors

>? 83289.diff
>Index: nsRenderingContextImpl.cpp
>RCS file: /cvsroot/mozilla/gfx/src/nsRenderingContextImpl.cpp,v
>retrieving revision 3.29
>diff -u -r3.29 nsRenderingContextImpl.cpp
>--- nsRenderingContextImpl.cpp	6 Feb 2002 15:37:21 -0000	3.29
>+++ nsRenderingContextImpl.cpp	16 Mar 2002 04:17:41 -0000
>@@ -887,8 +887,11 @@
>   nsPoint pt;
>   nsRect sr;
>-  pt = *aDestPoint;
>-  mTranMatrix->TransformCoord(&pt.x, &pt.y);
>+  float fX = float(aDestPoint->x), fY = float(aDestPoint->y);
>+  mTranMatrix->Transform(&fX, &fY);
>+  pt.x = NSToCoordRound(fX);
>+  pt.y = NSToCoordRound(fY);

Is nsTransform2D::TransformCoord's scale+translate case broken?  I don't see
why it should be rounding both terms of +, then adding.  Please file a bug,
note it here.

>   sr = *aSrcRect;
>   mTranMatrix->TransformCoord(&sr.x, &sr.y, &sr.width, &sr.height);
>Index: nsTransform2D.cpp
>RCS file: /cvsroot/mozilla/gfx/src/nsTransform2D.cpp,v
>retrieving revision 3.11
>diff -u -r3.11 nsTransform2D.cpp
>--- nsTransform2D.cpp	6 Nov 2001 01:28:27 -0000	3.11
>+++ nsTransform2D.cpp	16 Mar 2002 04:17:42 -0000
>@@ -405,8 +405,7 @@
> }
> void nsTransform2D :: TransformCoord(nscoord *ptX, nscoord *ptY)
>-  float x, y;
>+{  float x, y;

Argh, this is a gratuitous change, and ugly to boot.  Please undo, don't change
this file. with the above.


>   switch (type)
>   {
Attachment #74489 - Flags: superreview+
Comment on attachment 74489 [details] [diff] [review]
avoid the rounding errors

Attachment #74489 - Flags: approval+

Comment 163

17 years ago
fix checked in.
Last Resolved: 17 years ago
Resolution: --- → FIXED
I wrote:

>Is nsTransform2D::TransformCoord's scale+translate case broken?  I don't see
>why it should be rounding both terms of +, then adding.  Please file a bug,
>note it here.

What's the sequel bug?  Way to respond to my sr!


Comment 165

17 years ago
Brendan... I am not the authority here, but comment 153 does indicate that you
should ignore the nsTransform2D part of the patch... it was a typo. Hope that helps.

Comment 166

17 years ago
grabbed the nightly (2002032803).

looks good, no stripes.

Comment 167

17 years ago
Much better, but not perfect.
The stripes within the pictures are gone.
But I see sometimes a missing last line on the bottom or on the right
of a picture, e.g. in the last two pictures on

I use build 2002032803 on Win98 with 120 dpi.

Comment 168

17 years ago
um, am I the only one seeing bad image painting upon scrolling?  The fix for
this bug was supposed to fix this issue, but for me it made if *far* worse.  I'm
using build 2002033009 on Win2k (sp1sr1).  For instance, check out and make sure there is a vertical scrollbar.  Now
scrolldown and then scroll back up.  Notice the LibPr0n picture all broken up (I
will attach a screenshot after this post).  I also see this with all w3c
standards images and other images (not all).

I have my display resolution set to 96dpi (the Mozilla default on Windows)

So, did  this fix have this effect or is some other bug involved?  I dont'
remember seeing painting this bad for a long time.  Ever since this bug was
fixed is when I started seeing this behavior.  What's the deal?


Comment 169

17 years ago
Created attachment 76909 [details]
image showing image cruft after scrolling (96dpi on win2k)

Comment 170

17 years ago
That is bug 121230

Comment 171

17 years ago
*** Bug 129652 has been marked as a duplicate of this bug. ***

Comment 172

17 years ago
Verified fixed win xp build 2002041617, will check other OS's

Comment 173

17 years ago
*** Bug 109296 has been marked as a duplicate of this bug. ***


16 years ago
Keywords: adt1.0.1


16 years ago
Blocks: 143047
Keywords: mozilla1.0 → mozilla1.0.1
Whiteboard: [adt2] → [adt2 RTM] [ETA 06/27]

Comment 174

16 years ago
Adding adt1.0.1+ on behalf of the adt for checkin to the 1.0 branch.  When you
check this into the branch, please change the mozilla1.0.1+ keyword to fixed1.0.1
Keywords: adt1.0.1 → adt1.0.1+

Comment 175

16 years ago
this is already in. 
Keywords: fixed1.0.1

Comment 176

16 years ago
Verified fixed win xp branch build 2002072208, linux branch build 2002072306,
and Mac OS X branch build 2002072305
Keywords: fixed1.0.1 → verified1.0.1

Comment 177

14 years ago
it's baaaaaack
I'm seeing this with 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040518
but not with
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514

Many of the URLs mentioned here are gone and many do not reproduce the problem
for me, but

still does (see the spa .GIFs about 3/4s of the way down - also the upper left
and upper middle animated .GIFs near the bottom of the page, which also show
some weird artifacting during the animation).

I stumbled onto this today at

at the 2nd PowerPoint .GIF.  Finally, I saw something within the last few days

(stars1.gif was striping) - but I can no longer reproduce that one or the
original bug.

Comment 178

14 years ago
I see stripes with both
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040518
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514
although I don't see as many stripes with the latter and they come and go as I
mess with the font size.

Comment 179

14 years ago
I'm seeing this in spades with
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040601
(Classic theme, dark background, use system colors, always use my colors)

interesting related results in attached .PNGs:
most of the .GIFs here show the problem, but the left middle
one doesn't
the animated .GIF near the top of the page shows weird background-color
artifacts.  If you view it
by itself, it has no such problem

also, I'm seeing vertical background-color bars when using horizontal
scrolling at (but I won't post any images or URLs here,
'cause that'd be kinduva privacy violation.  I know some of y'all are
orkut members, though. . .)

Comment 180

14 years ago
Created attachment 149941 [details]
picture of some striped .GIFs at

Comment 181

14 years ago
Created attachment 149942 [details]
background-color pixel-wide artifacts from an animated .GIF

Comment 182

14 years ago
went away in 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
(except for the Verizon case; see
came back in 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040705
(noticed at , but the
 Tufte & psychic URLs just above reproduce it, too)

Not quite sure whether this should be expected with the split between trunk
and branch builds.

Comment 183

14 years ago
it's back again in
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
(aka released Firefox 1.0)

seen at
(on the Front Image, but not the Back Image)

The Tufte, psychic and Carnegie URLs (see above) show it, too.
You need to log in before you can comment on or make changes to this bug.