Closed Bug 83289 Opened 23 years ago Closed 22 years ago

Some images get background-color lines/stripes when scrolled

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: Peter, Assigned: pavlov)

References

(
URL
)

Details

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

Attachments

(10 files, 2 obsolete files)

Screenshot demonstrating problem (24bit display on Matrox G400)
44.07 KB, image/png
Details
Scrolling has bad effect on form elements' images
5.00 KB, image/png
Details
Screenshot of WildMagic site showing stripes
35.28 KB, image/png
Details
dropped line on scroll in text on OSX
52.84 KB, image/png
Details
Example of artifacts caused by scrolling the test URL
43.32 KB, image/gif
Details
list of img tags, native image size and whether I see stripes
3.14 KB, text/plain
Details
avoid the rounding errors
1.21 KB, patch
gagan
: review+
brendan
: superreview+
roc
: approval+
Details | Diff | Splinter Review
image showing image cruft after scrolling (96dpi on win2k)
175.22 KB, image/png
Details
picture of some striped .GIFs at salon.com
56.75 KB, image/png
Details
background-color pixel-wide artifacts from an animated .GIF
30.34 KB, image/png
Details 
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:
http://members.es.tripod.de/ssaammwweell/thumbs1.html

SPAM: Yes, those are some very cool Quake 3 wallpapers :)
Keywords: mozilla0.9.1
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
I'm definetely still seeing this on winNT, build 2001-05-30, voodoo3-3000,
1280x1024x64k colors, 228MB RAM
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 www.lemure.net,
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?
I see this under i386 Linux, build 2001060713.  Confirming, setting OS to All. 
Another URL where this occurs is
http://amber.mcs.kent.edu/~ryouko/LUNAR/HTMLS/Treasure.html.  Go down to the one
labeled "More Lunar Wallpapers!".  Note that a lot of the other images don't
have problems.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Target Milestone: --- → mozilla0.9.3
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.
See http://msdn.microsoft.com/library/techart/msdn_mfc4ce.htm

The first dialog box gif on the page doesnt have the problem but the next two do.
Hardware: PC → All
*** Bug 86278 has been marked as a duplicate of this bug. ***
Summary: Scrolling page with images (jpg) causes white lines in the images. → Some images get background-color lines/stripes when scrolled
Same problem on http://news.bbc.co.uk:

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

Reproducible: Always
Steps to Reproduces
1.open http://news.bbc.co.uk
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 
problem.


Bug 85804 shows PNG problems, as well.
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.

I have just been playing around, on:
http://members.es.tripod.de/ssaammwweell/thumbs1.html
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 http://news.bbc.co.uk, 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.
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: 
http://www.wild-magic.com/Applications/Applications.html

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.




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
doesn't. http://slashdot.org
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.
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 http://www.bbc.co.uk (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))

 
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. ***
*** Bug 89254 has been marked as a duplicate of this bug. ***
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.
I've got an additional comment...

I found out, that in the test-page at
  http://members.es.tripod.de/ssaammwweell/thumbs1.html
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??
*** Bug 89294 has been marked as a duplicate of this bug. ***
When I look at http://members.es.tripod.de/ssaammwweell/thumbs1.html I get the
white lines also (horizontal)


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:

http://www.entry.de/
I have the same problem with linux 2001061108 (e.g.:
http://www.proc.org/fandom/cons/garching/samstag.htm) 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.

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. ***
*** Bug 85062 has been marked as a duplicate of this bug. ***
*** Bug 85804 has been marked as a duplicate of this bug. ***
*** Bug 86695 has been marked as a duplicate of this bug. ***
bottom right image at http://www.kernel.org gets easily corrupted with scrolling

Odd... `powered by linux' on 2001062823 does not get mis-displayed no matter
what I do. In fact, nothing on kernel.org does.
The png test page at http://www.libpng.org/pub/png/pngs-img-bg.html 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
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
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
(http://www.libpng.org/pub/png/pngs-img-bg.html)... 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
size???


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.
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 kernel.org, the fox image on the bottom right.
This is fixed now. Maybe the removal of the old imagelib code fixed this.
To summarize by image type and web page, here is what I see on Windows 2000 with
2001081504 (1280x1024x32bits color):

1) http://members.es.tripod.de/ssaammwweell/thumbs1.html - This contains a bunch
of JPG files (quake 3 images), many of which (but not all) show the problem!

2) http://www.wild-magic.com/Applications/Applications.html - 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) http://www.entry.de/ -- 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 http://msdn.microsoft.com/library/techart/msdn_mfc4ce.htm
has been moved.

Hope this is helpful. 
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)
I can confirm the problem in Linux 4.06/X4.1/KDE 2.1.1 1600x1200x16 on 
http://members.es.tripod.de/ssaammwweell/thumbs1.html, 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.
You forgot to post your build number. 
Sorry about the build.  I built a CVS version 8/13/01.  I guess its a little
dated. ;)
Please get a new build asap and report back on all pages tested here.
egrochowski@vorum.com, 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.

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:

1) http://members.es.tripod.de/ssaammwweell/thumbs1.html
2) http://www.wild-magic.com/Applications/Applications.html - 
3) http://www.entry.de/

See instructions in my previous post for further comments on each page.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
I am still getting the horizontal lines on a Linux CVS build that just finished
a few minutes ago.
I retested http://members.es.tripod.de/ssaammwweell/thumbs1.html


*** Bug 84994 has been marked as a duplicate of this bug. ***
Further clue:
Using the page from http://www.wild-magic.com/Applications/Applications.html, 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"
border=1></td>

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! 


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


What happens when you put your resolution to 1024x768x16?
Try also resizing your browser window.
Target Milestone: mozilla0.9.5 → Future
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.
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): 
http://www.codeguru.com/algorithms/crc32.html

The dialog box at the top of the page. 

I certainly think this target milestone needs moving up... how does that get done?
bdubbs@swbell.net , 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?
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 2.95.2.1 and havn't been able to make a new Mozilla for a while due to a
build problem.  I'll try again tonight.
A fresh build from cvs (2001090111) still has the problem in Linux.
*** Bug 93744 has been marked as a duplicate of this bug. ***
I'm getting this problem quite often on Linux. I'm using Moz 0.9.4. An example
page is http://sunsite.org.uk/ 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.

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:
http://www.atthefaire.com/index.html; note that the _A Knight's Tale_ "poster"
image does _not_ have the problem, but the image directly below it _does_.
*** Bug 101538 has been marked as a duplicate of this bug. ***
this is a VERY visible bug and should be fixed before 0.9.5. 
11 duplicates, 18 votes.
mostfreq?
mostfreq isn't any more
( Have a look at http://bugzilla.mozilla.org/duplicates.cgi )

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
For me, this regressed between
http://ftp.mozilla.org/pub/mozilla/nightly/2001-09-04-08-trunk/mozilla-i686-pc-linux-gnu-sea.tar.gz
and
http://ftp.mozilla.org/pub/mozilla/nightly/2001-09-05-08-trunk/mozilla-i686-pc-linux-gnu-sea.tar.gz

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
(http://www.atthefaire.com/index.htm) 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.)

Thanks.

BTW, I'm running XFree 4.1.0.1 (Debian/unstable) ATI Mach64 1024x768x24bppx85Hz
on a 17" monitor.
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.
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
happening...)

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)
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?

*** Bug 95824 has been marked as a duplicate of this bug. ***
*** Bug 100708 has been marked as a duplicate of this bug. ***
*** Bug 103714 has been marked as a duplicate of this bug. ***
Patch in bug 104544 works for me (at least on one page I've tested).




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


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

*** 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.
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=1572
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?
*** Bug 110687 has been marked as a duplicate of this bug. ***
My XFree dpi is 100x100. Changing Mozilla's pref to read 96dpi fixed this
problem for me.
This fix:

http://bugzilla.mozilla.org/show_bug.cgi?id=110369

Fixed some image striping issues with odd DPIs.

Can we see if this was fixed?
Regarding comment #85 from Michael Kaply, it still is a problem for me at 72 dpi
with 
nightly build 2001111908. I can also confirm that after changing to 96dpi the
problem
disappears.
*** Bug 111215 has been marked as a duplicate of this bug. ***
This Screenshot is Mediaplayer window over Mozilla.
http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=394

Invalid area isn't rectangle,this case.
(http://www.be.wakwak.com/~tks/)

And this site has no table,but 0.9.6 reprodeced.
http://member.nifty.ne.jp/Kondoh/GO_TO/go_to.html
*** Bug 111708 has been marked as a duplicate of this bug. ***
*** Bug 111792 has been marked as a duplicate of this bug. ***
*** Bug 111888 has been marked as a duplicate of this bug. ***
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 4.1.0.1 / 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
<http://images.amazon.com/images/P/B00005OM54.01.THUMBZZZ.jpg>. This is when
displayed on the Amazon.com "Electronics > Categories > Computer Add-Ons >
Drives & Storage page" (no URL, sorry: They have session id in them).
Happening a lot less often now, but I still see this on certain specific images,
reproducably.

Example: the second to last image at:
  http://www.franken.de/users/deco/myfiles/editor.html
(image of red and yellow chao on beach, JPEG)


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:

  http://bigboss.dnsalias.com/repaint/test.html
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).
Using 75x75 in the x server and 96 dpi in mozilla makes me never see this bug

I think we should relnote this
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?
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:
http://www.wild-magic.com/Applications.html

Every image on this page displays this phenonmenon on my computer when scrolling.
seeing this at http://www.adobe.com/ 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 (
http://bugzilla.mozilla.org/attachment.cgi?id=17629&action=view
, 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.

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.
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
http://www.acme.com/licensemaker/licenses.cgi
).  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.
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. :-)
here's another funky, twisted datapoint:

a Google cache copy of a page ( http://www.dj.com/ ) shows
stripes, although the original page does not (I asked for
http://www.google.com/search?q=%22dow+jones%22+telerate&btnG=Google+Search
and poked the cache link, which was
http://www.google.com/search?q=cache:WvbNRGemNDY:www.dj.com/+%22dow+jones%22+telerate&hl=en
at the time I did this)

Wonder what that's all about. . .  Anyway, my config's at
http://bugzilla.mozilla.org/show_bug.cgi?id=83289#c100

OBTW, I tried http://www.acme.com/licensemaker/licenses.cgi
(mentioned in http://bugzilla.mozilla.org/show_bug.cgi?id=83289#c102 )
at a number of different DPIs and none of 'em striped for me. 

This only happens to me scrolling down. If I scroll down past an image, and then
back up it looks fine.
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 http://www.wild-magic.com/Applications.html. Go there and
scroll down as described above and voila.


hmmmm.   http://www.wild-magic.com/Applications.html works fine for
me.  And I get the stripes on http://www.adobe.com/ 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(???).

*** Bug 104374 has been marked as a duplicate of this bug. ***
I dont see it at www.adobe.com... 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.
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 wild-magic.com pages.

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

/kc
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
http://www.wild-magic.com/Applications.html when running Build 2001121003 on
Win2K at 1280x1024x32bit.


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.

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;
   aImage->GetCurrentFrame(getter_AddRefs(iframe));
   if (!iframe) return NS_ERROR_FAILURE;
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
http://www.madisonastro.org/check/problems/cal_2002_q1_bad_gif.html
(Half of the images break up)

and another at
http://www.clsurf.com/rasastro/
(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.

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. 
Bottom two scenes (4 images) at http://www.martinez-destreza.com/fenfot05.htm
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
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.
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 =(
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.
Merging with bug 116496.
URL: http://hacks.mit.edu/Hacks/by_year/20...
Severity: normal → critical
Keywords: nsbeta1, nsdogfood
Target Milestone: Future → ---
*** Bug 116496 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9.9
*** Bug 104544 has been marked as a duplicate of this bug. ***
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
http://www.mozilla.org/newlayout/xml/debugdemos/books/books.xml , 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
http://bugzilla.mozilla.org/show_bug.cgi?id=116593
I still experience this in 0.9.8 (on Win2000) at 1280x1024 using Large fonts.
The latest test URL (http://hacks.mit.edu/Hacks/by_year/2001/the_one_ring/)
works fine for me, but I still experience problems at
http://www.wild-magic.com/Applications.html
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?
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)
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.
Target Milestone: --- → Future
One page where I allways get broken textlines when scrolling up is
http://www.linux.org.uk/

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.

In reference to comment #128 - if you really think it's a nsTransform2D bug, you
may want to take a look at bug 97861...
Michiel: i tried your patch, but it does not work for me.
I use Win98 with 'large fonts' (120 dpi).
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 http://www.photo.net/gallery/
(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.
*** Bug 126015 has been marked as a duplicate of this bug. ***
Blocks: advocacybugs
per adt, critical for nsbeta1. hence plus.
Keywords: nsbeta1 → nsbeta1+
per adt, critical for nsbeta1. hence plus.
Whiteboard: [adt2]
Maybe you don't need more test cases, but on cvs-diff listnings from ViewCVS like

http://savannah.gnu.org/cgi-bin/viewcvs/savannah/savannah/gnuscripts/sf_cvs.diff?r1=1.32&r2=1.33&diff_format=h

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. ***
me again (config at http://bugzilla.mozilla.org/show_bug.cgi?id=83289#c100 ,
but I'm running 0.9.8 now).

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

        http://www.homeniscience.com/le_traversin/page1a.html

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.

(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

http://bugzilla.mozilla.org/show_bug.cgi?id=83289#c46

reported this, too, but

    http://www.homeniscience.com/le_traversin/page1a.html

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

Could you integrate all that into one HTML page, so that it could be easily
referenced for testing?
> 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

        http://www.homeniscience.com/le_traversin/page1a.html

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
.mozilla.org.  And it failed to exhibit the problem.  So, although

        http://bugzilla.mozilla.org/showattachment.cgi?attach_id=73563

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.
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
(http://www.homeniscience.com/le_traversin/page1a.html) 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!
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.

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
http://www.wild-magic.com/Applications.html
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.
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.
Target Milestone: Future → mozilla1.0
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
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 on attachment 74489 [details] [diff] [review]
avoid the rounding errors

r=gagan ignoring the nsTranform2D.cpp patch
Attachment #74489 - Flags: review+
please ignore the nsTransform2D part of the patch.  that was a typo when looking
at the file.
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.
I went back to 0.9.8 and replaced gkgfx.dll with a patched one kindly
supplied by egrochowski@vorum.com and the stripes at

    http://www.homeniscience.com/le_traversin/page1a.html

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

    http://www.computerhistory.org/events/lectures/engelbart_03262002/

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

http://www.mtelecom.ru

referenced in bug

http://bugzilla.mozilla.org/show_bug.cgi?id=62219

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

Comments go to that bug. Thanks.

Thanks
Curious. See also my bug 119824 and bug 88485, which could be related to this.
*** Bug 132930 has been marked as a duplicate of this bug. ***
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.
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 

    http://www.computerhistory.org/events/lectures/engelbart_03262002/  and
    http://slashdot.org/

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

    http://bugzilla.mozilla.org/show_bug.cgi?id=129400

(BTW, I didn't see any problem at

    http://www.mtelecom.ru

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

    http://bugzilla.mozilla.org/show_bug.cgi?id=132930

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.

sr=brendan@mozilla.org with the above.

/be

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

a=roc+moz
Attachment #74489 - Flags: approval+
fix checked in.
Status: NEW → RESOLVED
Closed: 22 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!

/be
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.
grabbed the nightly (2002032803).

     http://www.homeniscience.com/le_traversin/page1a.html

looks good, no stripes.

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

    http://www.photo.net/gallery/

I use build 2002032803 on Win98 with 120 dpi.
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
http://www.libpr0n.com/ 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?

Jake
That is bug 121230
*** Bug 129652 has been marked as a duplicate of this bug. ***
Verified fixed win xp build 2002041617, will check other OS's
Status: RESOLVED → VERIFIED
*** Bug 109296 has been marked as a duplicate of this bug. ***
Keywords: adt1.0.1
Blocks: 143047
Keywords: mozilla1.0 → mozilla1.0.1
Whiteboard: [adt2] → [adt2 RTM] [ETA 06/27]
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+
this is already in.
Keywords: fixed1.0.1
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
it's baaaaaack
 
I'm seeing this with 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040518
Firefox/0.8.0+
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

http://www.homeniscience.com/le_traversin/page1a.html

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 

http://www.edwardtufte.com/tufte/posters

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

http://www.richswebdesign.com/

(stars1.gif was striping) - but I can no longer reproduce that one or the
original http://bugzilla.mozilla.org/show_bug.cgi?id=227498 bug.


at http://www22.verizon.com/forhomedsl/channels/dsl/high-speed+connection.asp
I see stripes with both
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040518
Firefox/0.8.0+
and
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.


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

interesting related results in attached .PNGs:

http://www.salon.com/tech/wire/2004/05/27/spammer/index_np.html
most of the .GIFs here show the problem, but the left middle
one doesn't

http://www.scientificpsychic.com/graphics/
the animated .GIF near the top of the page shows weird background-color
artifacts.  If you view it
http://www.scientificpsychic.com/graphics/ascend.gif
by itself, it has no such problem

also, I'm seeing vertical background-color bars when using horizontal
scrolling at orkut.com (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. . .)
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
 http://bugzilla.mozilla.org/show_bug.cgi?id=248393)
came back in 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040705
Firefox/0.8.0+
(noticed at http://www.michaellorenzen.com/carnegie.html , 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.
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
http://www.cafepress.com/politics/browse/Nao-1_Ntk-All_pv-bettybowers.3932701_p-5_N-20407485_nr-1?zoom=yes#zoom
(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.

Attachment

General

Creator:
Created:
Updated:
Size: