Bad lines drawn over background images when zoomed

VERIFIED FIXED

Status

P2
major
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: mossop, Assigned: vlad)

Tracking

({regression})

Trunk
x86
Mac OS X
regression
Bug Flags:
blocking1.9 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

11 years ago
Created attachment 299199 [details]
screenshot

At certain levels of zoom I am seeing black lines appearing over the top of content, I think it is repeated background images. See the url and try zooming in or out, you should see the screenshot attached.

The occurs both drawing to a canvas element and to regular page zoom. The effect varies according to the zoom level.
Flags: blocking1.9?
(Reporter)

Updated

11 years ago
Attachment #299199 - Attachment description: creenshot → screenshot
(Reporter)

Comment 1

11 years ago
Regression from the cairo upgrade
Blocks: 411224
Duplicate of this bug: 413683
(In reply to comment #1)
> Regression from the cairo upgrade

Confirmed by dropping to an older version of cairo? By the date range?  Or which?
(Reporter)

Comment 4

11 years ago
Confirmed by comparing builds from the hourly build archive giving the following regression range:

http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1200690960&maxdate=1200692879
Assignee: nobody → vladimir
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Created attachment 299389 [details] [diff] [review]
scale the source image rect when tiling

roc, does this look like a reasonable thing to do?  The problem is that Quartz seems to always start a tile at integer coordinates, so if we have some scaling going on where the edges of images don't fall on integer coordinates, we get seams.  Here I try to specify a slight scale to the image so that it always completely covers the destination tile space once transformed.  It seems to work fine in my testing.
Attachment #299389 - Flags: review?(roc)
Why are you removing all the if (action == DO_IMAGE && op != CAIRO_OPERATOR_OVER) blocks?

This could change the output quite a bit. For example if we're scaling a 2px by 2px image by 0.5001 in each direction using a source transform, instead of getting something that's basically uniform (1px by 1px) we'll get the original image.

I'd be a lot more comfortable if we just checked that the source width and height are non-integers (maybe within epsilon) and if they aren't, take a fallback path.
Attachment #299389 - Attachment is obsolete: true
Attachment #299389 - Flags: review?(roc)
Created attachment 299458 [details] [diff] [review]
updated patch

Ok, here's a patch that only does DrawTiledImage if we're within epsilon of integer sizes after transforming.

The other chunks of code that are being removed are bits that I added a while back without thinking straight; they were intended to emulate cairo's "transparent black everywhere outside source bounds" behaviour, but for whatever reason I didn't think that to do that I'd have to explicitly clip out the region that the image was about to get draw into.
Attachment #299458 - Flags: review?(roc)
Checked in and upstreamed.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Flags: in-testsuite?
Status: RESOLVED → VERIFIED
visited a page (http://n3wb.com/forum), scaled up and down with no lines.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008012804 Minefield/3.0b3pre ID:2008012804
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.