The default bug view has changed. See this FAQ.

Rendering artifacts (extra borders/black,grey lines) around images at certain zoom levels

RESOLVED WORKSFORME

Status

()

Core
Graphics
RESOLVED WORKSFORME
7 years ago
6 years ago

People

(Reporter: Nickolay_Ponomarev, Assigned: jrmuizel)

Tracking

({regression, testcase})

Trunk
x86
Mac OS X
regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
1. Load http://www.google.com/intl/en_ALL/images/srpr/logo1w.png
2. Check the image appearance at different zoom levels:

(number of zoom-ins/outs from 100% zoom)
-5 horizontal line below the image
-4 lines at the bottom and right of the image
-3 line at the right
-2 ok
-1 line at the bottom
100%  - ok
+1 ok
+2 line at the right
+3 ok
+4 right, bottom borders
+5 grey line at the bottom
+6 ok
+7 right,bottom
+8 ok

This happens only on Mac for me (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a5pre) Gecko/20100516 Minefield/3.7a5pre)

This is a regression from bug 542605 (verified by backing out locally).

(and in case the build system failed me, testing with nightlies shows this regression range:
works: 2010-04-26-03  http://hg.mozilla.org/mozilla-central/rev/2968d19b0165
fail:  2010-04-27-03  http://hg.mozilla.org/mozilla-central/rev/29a6a85fab8e )
(Reporter)

Updated

7 years ago
Keywords: regression
That regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2968d19b0165&tochange=29a6a85fab8e

The cairo update seems like the most likely cause, but there are a bunch of other possibilities.
Er, sorry, I missed the line in comment 0 that said this is confirmed to be a regression from the cairo update.
(Reporter)

Updated

7 years ago
blocking2.0: --- → ?

Comment 3

7 years ago
Blocking 1.9.3 beta1, serious visual regression which is easy to reproduce.
blocking2.0: ? → beta1+
(Assignee)

Updated

7 years ago
Duplicate of this bug: 566771
(Assignee)

Comment 5

7 years ago
I believe this comes from EXTEND_NONE being fixed in the cairo quartz backend.
Switching to EXTEND_PAD could fix this.
Needs to hit _a_ beta, not necessarily _this_ beta.
blocking2.0: beta1+ → beta2+
I confirm the bug on Linux With Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a6pre) Gecko/20100616 Minefield/3.7a6pre

But with some different behaviors:

(number of zoom-ins/outs from 100% zoom)
-5 ok
-4 lines at the bottom and right of the image
-3 line at the right
-2 ok
-1 line at the bottom
100%  - ok
+1 ok
+2 ok
+3 ok
+4 right, bottom borders
+5 ok
+6 ok
+7 ok
+8 ok
Isn't this bug 567370 comment 0, or vice-versa?
this problem will be fixed after cairo update 562746...
Problem not reproducible with patch for next cairo update bug...

Current cairo is broken, and causing not only rendering problems but also stability issues like 569669
Depends on: 562746
See also bug 468496.
I think this is exactly the problem mentioned in bug 418494 comment 4. Removing the optimization fixes the problem.
Blocks: 418494
(Reporter)

Updated

7 years ago
Blocks: 577837
Assignee: nobody → jmuizelaar
blocking2.0: beta2+ → betaN+
Created attachment 497111 [details] [diff] [review]
use EXTEND_PAD on mac

Josh, if you can still reproduce this, can you apply this patch and see if it fixes the bug? It makes us use EXTEND_PAD correctly on OS X.
Attachment #497111 - Flags: feedback?(joshmoz)

Comment 13

6 years ago
Comment on attachment 497111 [details] [diff] [review]
use EXTEND_PAD on mac

I can't reproduce the problem on trunk and Mac OS X 10.6. I won't have access to a 10.5 box until next week.
Attachment #497111 - Flags: feedback?(joshmoz)
(Reporter)

Comment 14

6 years ago
I can't reproduce on 10.5 with steps from comment 0 anymore...
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
IMNSHO the patch should be applied even though the original problem is unreproducible, as it makes a special case go away.
You need to log in before you can comment on or make changes to this bug.