Closed Bug 324698 Opened 14 years ago Closed 13 years ago
upscaling an image causes misrendering
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
png does not render properly
Attachment #209605 - Attachment is obsolete: true
Summary: Opacity is wrong → a png is not rendered properly
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)
Status: NEW → RESOLVED
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)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Yeah, not fixed yet, sorry :) But thanks for the reminder, though!
Assignee: nobody → vladimir
Status: REOPENED → NEW
14 years ago
Status: NEW → ASSIGNED
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: http://couven.dyndns.org/if12-R%fc/mathe-projekt/Jonny/test/test.htm 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=309036> 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?
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 341281 has been marked as a duplicate of this bug. ***
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 https://bugs.freedesktop.org/show_bug.cgi?id=2488 - 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. ***
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.
Whiteboard: cairo → cairo [blocking1.9a1+]
Whiteboard: cairo [blocking1.9a1+] → cairo
On my system (Debian GNU/Linux 4.0 -- or very close to it), at <http://thefump.com> 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
Duplicate of this bug: 371316
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)
Attachment #265603 - Flags: review?(roc) → review+
I've filed bug 381661 for reenabling this once the underlying bugs are fixed.
Patch to disable checked in.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago → 13 years ago
Resolution: --- → FIXED
Verified on www.thefump.com and comment #3 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070523 Minefield/3.0a5pre
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.