On http://www.real.com/, I'm seeing horizontal lines that are unpainted in the three images partway down the page (currently "Survivor: Africa", "MLB.com", and "America Fights Back"). The culprit appears to be a damage rect passed to nsImageFrame::Paint which isn't on a whole pixel boundary, and we round up when we need to be truncating. Since rounding is of course imprecise, the only way to be sure we paint everything that needs painted is to round the damagerect out. Patch coming up.

Might cure bug 83289 and/or bug 63336? I don't see those, and i don't see this one - but they're often reported.

i didn't see it when using 96dpi, but setting resolution in moz to 100 i see the stripes. Building with the patch: Stripes are gone, but another oddity appears: Make a "selection" stretching from below to above the images. (Click in contentarea - hold in, and drag upwards to select whatever is there or not) Result: The three upmost images will make a little "dive", being placed slightly further down the page as they get selected. Another site reported with stripe problem shows a similar behaviour: With dpi set to 100, go to http://www.entry.de/ In the while area to the right of the blue country-map; start a selection as described above, and drag upwards. As the drag reaches top of page, a white vertical line displays between the "Entryde" image and the other, "menubar" images. Clicking to the left of the "Entryde" image makes it snap back in place again.

If i set "Display resolution" to "system setting", i don't see stripes or jumping either way. Not sure how Moz reads system defaults, but xdpyinfo shows screen-resolution 98x104 dpi

also appering in win2k

Confirming. I also see this horizontal lines over images with M0.9.5 on current Red Hat Rawhide Linux. Isn't this somehow related to bug 104198 (Horizontal black lines appear scrolling the window)?

I can confirm that the patch fixes the problem for me. This problem looks like another manifestation of bug 83289 which I have been seeing since at least May 2001. The only difference is that "usually" the lines are manifest after a clip/repaint sequence. I am running Win2K at 1280x1024x32 with Large Fonts (120 dpi). The patch also fixes Bug 83289 for me (I already made a comment on that bug). Can we get it approved and in the tree?

bryner's patch worksforme on NT and W2K. Stuart claims (in email) that he's still waiting on bryner to test on windows and for printing.

I think something somewhere made this break off of bug 83289. It used to be that for any given image, I would see both hort. and vert. lines, but now, they don't seem to be related. I don't see what this has to do with bug 63336. This problem only shows up on images that have the height and width specified and equal to the actual image dimentions. I doubt that when I move the pop-up window over something, it moves in fractional pixels.

hinting back and forth between this one and bug 97861

This fix: http://bugzilla.mozilla.org/show_bug.cgi?id=110369 Fixed some image striping issues with odd DPIs. There are a few different issues at work here.

What is the review status of the patch?

110369 seemed to fix some sites for me, but I still see lines through 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've also seen text become unaligned by 1 pixel when scrolling, for example, a lowercase "L" would be: # # # # # # and all the rest of the text on that line has the top portion (whatever was on the screen before hiting down arrow) shifted 1 pixel left. I think this should be duped to 83289 or vise-versa.

I've seen the misaligned text problem too, but I believe that's a different bug -- the image and font code is separate.

This seems to be fixed by the checkin for bug 110474.

I can confirm that this is still a problem with the page Jeremy Dolan refered to. I am using build 2001121008 on Linux, so the patch should be in this build since bug 110474 was checked in on November the 11th. The patch did seem to fix the majority of the this class of problem, but there is still something else going on here. Check out the last two images at the bottom: http://www.franken.de/users/deco/myfiles/editor.html

taking

Comment on attachment 53409 [details] [diff] [review] patch r=pavlov

Comment on attachment 53409 [details] [diff] [review] patch sr=jag

Comment on attachment 53409 [details] [diff] [review] patch rs=brendan@mozilla.org -- the old code sure looks wrong and confused. /be

checked in.

This patch is causing odd artifacts at the right and bottom of images in the chrome. Since I haven't yet understood exactly what the problem is, I'm backing this out for 0.9.8.

Pavlov, I'm kicking this back over to you because I don't really have any time to spend on this.

The problem is with images sliced using -moz-image-region. Images are now including an extra pixel on the right and bottom. With normal images this is not a problem because there are no pixels to paint. But with a sliced image parts of the next slices appear.

As to weird effects, my build with that patch had white lines scrolling down images after loading. Just once, every 20-30 pixels or so. (pure guess) (Solaris, cvs Jan 16, I checked for the code part that I had this patch applied)

Can you people who are seeing the symptom please try bryner's patch in this bug? If it does help, then we need to figure out why it regressed other drawing (maybe there's another, presumably XP, drawing bug that is hiding behind the lack of bryner's fix). Thanks, /be

I am told that my problem here is due to this bug. 1. go to http://economist.com/agenda/displayStory.cfm?Story_ID=964765 2. scroll down to the long vanguard ad with the ship 3. scroll up and down rapidly. The image has real trouble repainting while the image is being dragged.

I am afraid I can't get the appropriate C++ compiler, get the sources, apply the patch and compile... but I will gladly test new binaries. Could you please include it in some of the nightbuilds? Thank you. PS: build 2002012903 still does that on my Windows NT 4.0

er, ok. let's make this a dup of 83289. *** This bug has been marked as a duplicate of 83289 ***