Closed Bug 324698 Opened 14 years ago Closed 13 years ago

upscaling an image causes misrendering


(Core :: Graphics, defect)

Not set





(Reporter: Peter6, Assigned: vlad)


(Blocks 1 open bug)


(Keywords: regression, Whiteboard: cairo)


(3 files, 2 obsolete files)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060123 Firefox/1.6a1 ID:2006012317 (Cairo)

The testcase should show a 100x100 px red tranparent square

testcase coming
Attached file testcase (obsolete) —
Whiteboard: cairo
Attached file testcase (obsolete) —
png does not render properly
Attachment #209605 - Attachment is obsolete: true
Summary: Opacity is wrong → a png is not rendered properly
Attached file testcase
upscaling an image causes misrendering
this should remain a red square
Attachment #209609 - Attachment is obsolete: true
Summary: a png is not rendered properly → upscaling an image causes misrendering
Fixed by one of the last patches (I guess vlads)
Closed: 14 years ago
Resolution: --- → FIXED
(In reply to comment #4)
> Fixed by one of the last patches (I guess vlads)

Duh, it helps if i test with a cairo build , reopening (sorry for the spam)
Resolution: FIXED → ---
Yeah, not fixed yet, sorry :)  But thanks for the reminder, though!
Assignee: nobody → vladimir
This is a cairo/pixman scaling bug it turns out; not in the way we're calling cairo.  Upscaling with a nearest-neighbor produces the correct results.  Working on a fix.. (It looks like cairo doesn't correctly align the first pixel when upscaling to be in the center of the region which will have coverage for that pixel, so everything gets pushed up and left)
*** Bug 328868 has been marked as a duplicate of this bug. ***
Downscaling images also has some problems. I'm not really sure if this is related, but check this testcase: 
and the last testcase in Bug 98971

You may want to compare Opera's rendering.
Not related; downsampling is still nearest-neighbor filtering, which is picking the white/black pixels.
(In reply to comment #10)
> Not related; downsampling is still nearest-neighbor filtering

Is there a reason why that's still the case? Downsampling is just as important, especially since large standalone images are now automatically sized down.
(In reply to comment #11)
> (In reply to comment #10)
> > Not related; downsampling is still nearest-neighbor filtering
> Is there a reason why that's still the case?

Because noone's implemented downsampling yet.

Someone has reported similar problems <> for raster images rendered as SVG image elements in SVG documents. Is that simply a dupe of this bug as fixing Cairo would fix SVG image rendering as well?
Blocks: 309036
Flags: blocking1.9a1+
OS: Windows 2000 → All
Hardware: PC → All
Blocks: 328388
Depends on: cairoperf
Blocks: cairoperf
No longer depends on: cairoperf
No longer blocks: cairoperf
No longer blocks: 334512
*** Bug 341281 has been marked as a duplicate of this bug. ***
Flags: blocking1.9+
Keywords: regression
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060807 Minefield/3.0a1 ID:2006080705 [cairo]

The behavior has changed since this bug was originally filed, I assume due to the fix at - now the testcase square fades to white at all four borders, not just the bottom and right borders. This is still undesirable IMO.
*** Bug 350107 has been marked as a duplicate of this bug. ***
Attached file another test case
an easier way to show the same bug
The above testcase should show a solid black bar.  The bug causes it to blend to bgcolor at table borders, making the bar have several gradient style fills.
Just a brain dump of how to fix this:

We need to implement a new mode within pixman which will:

1) ignore any sample locations that are outside of the source image bounds (render as transparent);
2) always snap to within the source image bounds when sampling within the image.

That is, there should be a discontinuity when sampling near the edge of the image when the center of the sampling area moves outside of the image bounds.

There is no existing cairo mode for this, so something new will need to be added.  Along the way, implementing the PAD mode for images would also be useful -- PAD just means that all samples go to the nearest actual source pixel, whether the sample point is within the image source or not.
Flags: blocking1.9a1+
Whiteboard: cairo → cairo [blocking1.9a1+]
Whiteboard: cairo [blocking1.9a1+] → cairo
Duplicate of this bug: 375816
On my system (Debian GNU/Linux 4.0 -- or very close to it), at <> with GIF images (seen on the blue ones - bg_top.gif and blue_left.gif):
doesn't happen on trunks 2006011004-2006040607
happens on trunks 2006041004-2007042704
sorry, happens on trunks since 2006040704.
Target Milestone: --- → mozilla1.9beta1
Ok, this bug has sat around for long enough.  I want to get this workaround in, in case we don't manage to get a real fix in for this for 1.9 -- the real fix involves doing a bunch of generic cairo work that I hoped would be done by now.  This problem does not appear on XP_MACOSX -- the Quartz surface does the right thing here as far as image scaling.

This ends up disabling bilinear filtering for upsampled images, returning our rendering to what it was in Fx2.  We'll have to live with this until a real fix is done.
Attachment #265603 - Flags: review?(roc)
I've filed bug 381661 for reenabling this once the underlying bugs are fixed.
Patch to disable checked in.
Closed: 14 years ago13 years ago
Resolution: --- → FIXED
Verified on and comment #3 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070523 Minefield/3.0a5pre
Flags: in-testsuite?
Flags: in-testsuite? → in-testsuite+
Depends on: 426803
You need to log in before you can comment on or make changes to this bug.