Closed Bug 490997 Opened 15 years ago Closed 12 years ago

image scaling produces grey line artifacts at some downscaling percentages

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
1.9.0 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: thompdump, Unassigned)

References

Details

Attachments

(3 files)

first test image
407 bytes, image/jpeg
Details
second test image (short3-full.jpeg)
544 bytes, image/jpeg
Details
self-contained test page
1.37 KB, application/xhtml+xml
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10

Image scaling in firefox exhibits line artifacts with certain images at certain scaling values. A screenshot is at http://datlisp.blogspot.com/2009/05/firefox-image-scaling-and-line.html

In this example, two images are each rendered at three different width values: 100%, 70%, and 50%. The second pink bar image, with a black smudge in the upper left corner exhibits grey lines at the left and top borders of the image when scaled to 50%. This doesn't seem to be ideal scaling behavior.

What next steps should I take? Stuff I have/haven't tried:
- haven't been able to try this on a windows box so am unable to tell if it's some sort of X windows-related issue
- tried it running firefox remotely on a sparc box and the same lines show up
- the grey lines don't appear when the page is viewed with opera
- tried jpeg, gif, png - same artifact occurs in each case

Reproducible: Always

Steps to Reproduce:
1. test XHTML below
2. test images are at http://dathomp1.googlepages.com/

<h:html xmlns:h="http://www.w3.org/1999/xhtml">
 
<h:body>
<h:div>100%:
  <h:img src="./short2-full.jpeg"
     width="100%"
     style="border-color: blue; border-width: thin; border-style: solid;
        padding: 2px;" />    
</h:div>

<h:div>70%:
  <h:img src="./short2-full.jpeg"
     width="70%"
     style="border-color: blue; border-width: thin; border-style: solid;
        padding: 2px;" />    
</h:div>

<h:div>50%:
 <h:img src="./short2-full.jpeg"
    width="50%"
    style="border-color: blue; border-width: thin; border-style: solid;
           padding: 2px;" />    
</h:div>


<h:div>100%:
 <h:img src="./short3-full.jpeg"
    width="100%"
    style="border-color: blue; border-width: thin; border-style: solid;
           padding: 2px;" />    
</h:div>

<h:div>70%:
 <h:img src="./short3-full.jpeg"
    width="70%"
    style="border-color: blue; border-width: thin; border-style: solid;
           padding: 2px;" />    
</h:div>

<h:div>50%:
 <h:img src="./short3-full.jpeg"
    width="50%"
    style="border-color: blue; border-width: thin; border-style: solid;
           padding: 2px;" />    
</h:div>

</h:body></h:html>
The last comment at http://forums.mozillazine.org/viewtopic.php?f=9&p=6014035 suggests another bug has been filed for (apparently) the same issue.
Attached image first test image — 

    
    

    
  


  

    
    

    
  


  
self-contained test page referencing image attachments

    
  
Component: General → GFX: Thebes
Product: Firefox → Core
QA Contact: general → thebes

    
  
Version: unspecified → 1.9.0 Branch

    
    

    
  
I don't see these artifacts when opening your testcase here (attachment 375343 [details]) with Firefox 3.0.10 on Ubuntu 9.04 (Mozilla official build). Maybe this could be Xserver/driver related.

    
    

    
  
Could be bug 411831. What is your distribution / Xserver version?

    
    

    
  
Apologies for not providing more detail. This does seem to be X-related -- but the symptom set doesn't precisely match that of 411831.

Debian unstable (sid)

xorg                                 1:7.4+1
xserver-xorg                         1:7.4+1
xserver-xorg-core                    2:1.6.1-1

X claims it's using EXA in the log: EXA: (==) intel(0): Using EXA for acceleration

inconsistent with description of bug 411831:
- setting "XAANoOffscreenPixmaps" doesn't resolve problem (not surprising since EXA is being used...)
- the 'black box' problem (comments 103/107) isn't observed
- the 'invisible image' problem (comment 104) isn't observed

consistent with bug 411831:
- grabbing the image and dragging shows the correct image in the drag window (consistent with comment 99).

Interestingly, the gray line artifacts aren't present when acceleration is turned off (Option "NoAccel"). Perhaps this behavior is limited to the intel video driver (and thus only affects a few users)?

    
    

    
  
Thanks for the detailed information. This issue looks like bug 472472 which has been marked as a duplicate of bug 411831, but this one (and maybe bug 472472) could be something else according to the inconsistent symptoms.

It would also be interesting if you could test with Firefox 3.5 or 3.6 (available at http://www.mozilla.com/en-US/firefox/all-beta.html and http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ respectively).

That looks like a Xserver/driver issue so it isn't likely that lots of efforts will be spent fixing this on branch (Firefox 3.0). But if it is still showing on 3.5, then it's a different deal.

    
    

    
  
The symptoms I observe are identical to those described for bug 472472 (e.g., zooming in at www.reddit.com or www.google.com yields images with gray lines at the top and left of the image; www.mozilla.org has images which are affected as well as images which aren't affected).

The behavior occurs in minefield (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090502 Minefield/3.6a1pre)

Perhaps bug 472472 is not a duplicate of bug 411831 -- although both seem related to X server acceleration.

    
    

    
  
I have been seeing this behavior in Firefox ever since upgrading Ubuntu from Intrepid to Jaunty, readily reproducible by zooming out or viewing a web site that contains scaled images.  I'm pretty sure I had the same version of Firefox both before and after the upgrade; I believe the change in behavior may have been triggered by a change in video driver configuration, from the "fglrx" video driver to the "radeon" driver; note that I am not using the "intel" video driver like the previous commenter, so this bug does affect more than just "intel" users.  As above, attempting to set XAANoOffscreenPixmaps doesn't help, and results in a message that the option is being ignored, probably because the X server claims to be using EXA and not XAA.  This is a 64-bit system, in case that turns out to matter.

I'd readily switch back to "fglrx" but so far my attempts to do so have resulted in a completely unusable system, for (what I assume are) unrelated reasons.  I will verify that Option "NoAccel" makes the symptoms go away and follow up if it fails to behave as expected, but I fear that's not likely to be a viable long-term workaround for performance reasons.  This rendering glitch is a serious problem for me as I use this machine for web design, among other things.

If anyone has run across any kind of viable workaround for this problem, or has a suggestion of something to try, I'm sure I'm not the only one who would enjoy hearing about it!

    
    

    
  
The first thing would be to try with Firefox 3.5 and see if the problem is gone (firefox-3.5 package in Jaunty, or can be downloaded from http://www.mozilla.com/en-US/firefox/all-beta.html).

Then checking if the issue is still there with the "NoAccel" option can answer if the issue is in Firefox or your graphic card driver.

If the issue is with your graphic card driver, then Firefox can't do much about it unfortunately (except bypassing XRender but that's not for the immediate future).

    
    

    
  
The same problem seems to affect firefox-3.5 as well.

Option "NoAccel" did indeed seem to make the problem go away, but also gave me a warning about "low graphics mode" and reverted my dual-monitor setup to a mirrored configuration.  Which could be expected behavior, for all I know.  Either way, it suggests that the X server configuration is indeed a factor.

I very much doubt this will turn out to be Firefox's fault, though it doesn't seem to me that any number of xorg.conf experiments can prove it isn't  -- Firefox could conceivably be doing something wrong that usually happens to work but occasionally causes problems under complex circumstances.

I'm tempted to try to put together a repro case for this bug that doesn't involve Firefox at all, but I evidently don't have a clear enough idea of how Firefox actually renders images to have succeeded in reproducing the artifact thus far.  I've got a toy program here that pops up a window containing a scaled raster image on a white background (using cairo, which I have a vague idea that Firefox might also use), but of course it renders without any artifacts.  Ah well.

    
    

    
  
Firefox uses Cairo [1] for the rendering, so you could write a small Cairo program that does what Firefox does, so you can reproduce the issue without Firefox.
But the real issue is apparently with your graphic card driver, so you could report the issue to the driver authors. Having a small test program can surely help the driver authors to isolate the issue more quickly than having to run Firefox.
It would be even better to make the testcase use the XRender X11 extension directly, that's what Cairo uses on X11. Here's an example of such a testcase: http://lists.freedesktop.org/archives/xorg/2008-February/032973.html

[1] http://cairographics.org/

    
    

    
  
Any update on whether this is something Mozilla will be working on? While the issue is apparently hardware/driver related (see above), note that the problem is unique to Gecko; the artifacts don't appear in browsers such as Midori (see bug 497813).

    
    

    
  
does using XAA or NoAccel solve the problem?
most likely a bug in the Intel-Video driver: http://bugs.freedesktop.org/show_bug.cgi?id=21523

    
    

    
  
NoAccel 'solves' the problem (see comment #7, above)

    
    

    
  
The NoAccel fix doesn't seem to be fixing the problem for me. My xorg.conf file is below. I've tried shutting down and clearing the cache. I've tried Option "NoAccel" "yes", Option "NoAccel", and Option "NoAccel" "true". What am I missing? 

# Xorg configuration created by system-config-display

Section "ServerLayout"
	Identifier     "single head configuration"
	Screen      0  "Screen0" 0 0
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"

# keyboard added by rhpxl
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "pc105+inet"
	Option	    "XkbLayout" "us"
EndSection

Section "Monitor"
	Identifier   "Monitor0"
	ModelName    "LCD Panel 1024x768"
	HorizSync    31.5 - 48.0
	VertRefresh  56.0 - 65.0
	Option	    "dpms"
EndSection

Section "Device"
	Identifier  "Videocard0"
	Driver      "intel"
	Option	    "NoAccel" "true"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Videocard0"
	Monitor    "Monitor0"
	DefaultDepth     24
	SubSection "Display"
		Viewport   0 0
		Depth     24
	EndSubSection
EndSection

    
    

    
  
Seeing this bug with an nvidia card (tested with "nv" and "nvidia" drivers).

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.2) Gecko/20090803 Ubuntu/9.04 (jaunty) Shiretoko/3.5.2

How can this be a hardware/driver issue if it seems to be a Gecko specific rounding error?

    
    

    
  
The same problem occurs for HTML5 embedded <video>s.

If any (!) pixel of an image is transparent, then the problem goes away.

Does any of this shed any light on the Gecko vs. Cairo question?

    
    

    
  
If pixels are transparent, then Cairo won't be able to transform an OVER into a SOURCE, so it might use an entirely different codepath in the X server.

    
    

    
  
After upgrading Ubuntu from Jaunty to Karmic, I am no longer seeing any of the problems I described in my earlier comments.

    
    

    
  
I use karmic as shipped and the problem still exists for me using Intel 945GME chipset on a Dell Mini 10v. Also on Ubuntu 9.10 firefox-3.5-3.5.3+build1+nobinonly-0ubuntu6, xserver-xorg-7.4+3ubuntu7, xserver-xorg-video-intel-2.9.0-1ubuntu2

Also exists on latest Fedora 11 / Firefox 3.5.5 with Nvidia ION chipset using the RPM Fusion NVIDIA binary drivers (Acer Revo, xorg-x11-drv-nvidia-libs-190.42-1.fc11.i586, xorg-x11-server-Xorg-1.6.4-0.1.fc11.i586)

    
    

    
  
Hi there, I am Karmic Koala user. Fact is: Unwanted borders are visible only in localhost produced webpages, uploaded webpage is displayed correctly. My laptop is HP Pavilion 2104EA (GA is Intel 945GME). Opera displays the same web always correctly (from loc and remote server), seems to be FF bug only. Is there some special way FF uses GA driver?

    
    

    
  
Hello, I'm using Karmic Koala as well. The black/gray borders are visible in all images that have been scaled down with CSS or width="" height="". For example the logo on Guardian's website looks like this to me: http://i.imgur.com/GE8SE.gif. Opera displays the image without the border. 

Is there a fix available?

    
    

    
  
I have the exact same issue and using FF 3.6.8 on Ubuntu 10.04 LTS - the Lucid Lynx. The issue is on scaled down images. Its been over a year that we have this problem. Please let us know how to fix this or report to the OS bug report if it is OS related.

Thanks...

    
    

    
  
See bug report https://bugzilla.mozilla.org/show_bug.cgi?id=598890
Should be grouped with similar bugs about artifacts when scaling on any operating system, since these bugs seem to be a symptom of a larger bug.

    
    

    
  
Can you retest this please now that bug 468496 is fixed?

    
    

    
  
Seems like this is likely fixed. Reopen if not.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: