Last Comment Bug 504071 - "-moz-transform: scale" draws seams between tiled images
: "-moz-transform: scale" draws seams between tiled images
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal with 3 votes (vote)
: mozilla20
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
:
:
Mentors:
http://www.maryanovsky.com/sasha/scal...
: 842968 (view as bug list)
Depends on: 862323 865546 896249
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-14 05:37 PDT by Alexander Maryanovsky
Modified: 2013-07-28 13:27 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
simplified testcase based on comment #6 (504 bytes, text/html)
2012-12-03 18:00 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
fix (2.78 KB, patch)
2012-12-03 18:25 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
fix (3.61 KB, patch)
2012-12-03 18:26 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
joe: review-
Details | Diff | Splinter Review
testcase for non-simple images (3.78 KB, text/html)
2012-12-04 14:47 PST, Joe Drew (not getting mail)
no flags Details
fix v2 (5.59 KB, patch)
2012-12-04 15:34 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
fix v3 (6.22 KB, patch)
2012-12-07 02:55 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
fix v4 (7.72 KB, patch)
2013-01-02 23:35 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
joe: review+
Details | Diff | Splinter Review

Description Alexander Maryanovsky 2009-07-14 05:37:12 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

Tiled images with no space between them that are scaled using "-moz-transform: scale" will draw "seams" between the images. In the linked test page, 9 solid-color images are placed in a 3x3 grid with no space between them. After a few seconds, they will be scaled to twice their size and back. While they are scaled, you can see white (or whatever the body background color is) lines between the images.

This issue, for example, prevents "transform: scale" from being used in applications like Google Maps, to implement continuous zoom.

Reproducible: Always

Steps to Reproduce:
1. Open the attached URL.
2. Wait a few seconds.

Actual Results:  
White lines appear between the tiles.

Expected Results:  
A completely solid-color rectangle should be seen, with no lines between the tiles.
Comment 1 bz 2009-09-15 11:38:05 PDT
here one more example:

http://lamp2.fhstp.ac.at/~lbz/beispiele/ws2009/firefox/
Comment 2 nicolas toniazzi 2010-01-07 01:51:34 PST
Problem on Linux too with firefox 3.5 to 3.7a1.

All "transform" functions badly handle images. In the following example, they draw a scaled black line around the picture. No black color is defined anywhere (border, background, etc.)

Webkit on the same platform shows scaled borders, but no black line.

http://toniazzi.net/Bugs/firefox-transform-1.html
Comment 3 Aryeh Gregor (:ayg) (away until October 25) 2012-02-14 10:23:48 PST
Minimal test-case:

data:text/html,<!doctype html>
<style>img { height:20px;width:20px }</style>
<div style="width:40px;-moz-transform:scale(4.16);-moz-transform-origin:0 0">
<img src="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'><rect width='20' height='20' /></svg>"
><img src="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'><rect width='20' height='20' /></svg>">

I see a crack in between the two images on Firefox 13.0a1, Ubuntu 11.10 with nouveau+Gallium3D.
Comment 4 R de Wit 2012-05-17 05:34:32 PDT
It looks like the upcoming version of OpenLayers (2.12) suffers from this bug too, as can be seen by this test case:

http://rdewit.net/tmp/white-line-bug.html (click on 'Launch OL 2.12 Window', then click on 'Start Animation' in the popup window).

The corresponding bug report in OpenLayers can be found here: https://github.com/openlayers/openlayers/issues/458
Comment 5 eric.lemoine 2012-05-19 07:21:19 PDT
The issue in OpenLayers has nothing to do with -moz-transform. The issue in OpenLayers is related to OpenLayers positioning images using % instead of px. I've managed to reproduce the problem outside OpenLayers, in a minimal example:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

    <style type="text/css">
        #container {
            margin: auto; /* without this the issue goes away */
            width: 900px;
            height: 600px;
        }
    </style>
    <div id="container">
        <div style="width:100px; height: 100px; position: absolute">
            <img src="http://vmap0.tiles.osgeo.org/wms/vmap0?LAYERS=basic&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&FORMAT=image%2Fjpeg&SRS=EPSG%3A4326&BBOX=0,33.75,11.25,45&WIDTH=256&HEIGHT=256" style="left:236%; top:136%; width: 256%; height: 256%; position:absolute" />
            <img src="http://vmap0.tiles.osgeo.org/wms/vmap0?LAYERS=basic&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&FORMAT=image%2Fjpeg&SRS=EPSG%3A4326&BBOX=11.25,33.75,22.5,45&WIDTH=256&HEIGHT=256" style="left:492%; top:136%; width: 256%; height: 256%; position:absolute" />
        </div>
    </div>
    <div>

        <p>In FireFox if the width of the browser window is an odd number then
        a white line appears between the images. If <code>margin: auto</code>
        is removed for the container the issue goes away.</p>

        <p>Note: the computed value for <code>left</code> of the image on the left
        in 235.983px in FireFox.</p>

    </div>
  </body>
</html>
Comment 6 Dave Leaver 2012-10-14 19:03:14 PDT
Here is another Example on JSFiddle:
http://jsfiddle.net/vYvhZ/11/
In chrome this always shows as a white box with no line between, on Firefox there is a line between the 2 boxes. The amount of fallthrough seems to vary by browser window size.

This issue also affects leaflet (web map library)
https://github.com/CloudMade/Leaflet/issues/1066
Comment 7 Brad Vogel 2012-11-12 15:30:26 PST
Bump. This would be great to fix. Image tiling libraries aren't very useful in FF.
Comment 8 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-03 17:59:38 PST
This bug seems to have become a grab-bag of different issues involving seams...

(In reply to Alexander Maryanovsky from comment #0)
> Actual Results:  
> White lines appear between the tiles.

I see this sometimes, but the testcase is more complicated than is probably necessary.

(In reply to bz from comment #1)
> http://lamp2.fhstp.ac.at/~lbz/beispiele/ws2009/firefox/

Seems to work fine for me on Windows 7 with D2D enabled.

(In reply to nicolas toniazzi from comment #2)
> http://toniazzi.net/Bugs/firefox-transform-1.html

Seems to work fine for me on Windows 7 with D2D enabled.

(In reply to :Aryeh Gregor from comment #3)
> I see a crack in between the two images on Firefox 13.0a1, Ubuntu 11.10 with
> nouveau+Gallium3D.

I see this problem, but it's a different bug since it involves SVG and this bug as filed does not (and the code paths involved are rather different).

(In reply to Roald de Wit from comment #4)
> http://rdewit.net/tmp/white-line-bug.html (click on 'Launch OL 2.12 Window',
> then click on 'Start Animation' in the popup window).

Seems to work fine for me on Windows 7 with D2D enabled.

(In reply to Dave Leaver from comment #6)
> Here is another Example on JSFiddle:
> http://jsfiddle.net/vYvhZ/11/
> In chrome this always shows as a white box with no line between, on Firefox
> there is a line between the 2 boxes. The amount of fallthrough seems to vary
> by browser window size.

This is a great testcase which probably matches this bug as filed. Thanks!
Comment 9 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-03 18:00:39 PST
Created attachment 688065 [details]
simplified testcase based on comment #6
Comment 10 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-03 18:25:20 PST
Created attachment 688070 [details] [diff] [review]
fix

The problem is simply that our all-pixels-same-color image drawing path does not do pixel snapping.
Comment 11 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-03 18:26:38 PST
Created attachment 688072 [details] [diff] [review]
fix

Updated patch
Comment 12 Dave Leaver 2012-12-03 19:47:19 PST
Awesome! Thank you for your work on this one Robert :-)
Anything else I can do to help, just shout out.
Comment 13 Joe Drew (not getting mail) 2012-12-04 13:48:33 PST
Comment on attachment 688072 [details] [diff] [review]
fix

Review of attachment 688072 [details] [diff] [review]:
-----------------------------------------------------------------

This does seem to work, but it seems that it's incompatible with what DrawToPixelSnapped does, so if you make your test images more complex, the seam reappears (like: http://i.imgur.com/luNJk.png)

Simply pixel-snapping gfxDrawable doesn't work, presumably because DrawToPixelSnapped has snapped it slightly incorrectly.

Anyways, I'm r- because it makes our behaviour inconsistent, not because this is wrong.
Comment 14 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-04 14:36:27 PST
(In reply to Joe Drew (:JOEDREW! \o/) from comment #13)
> This does seem to work, but it seems that it's incompatible with what
> DrawToPixelSnapped does, so if you make your test images more complex, the
> seam reappears (like: http://i.imgur.com/luNJk.png)

Can you upload that testcase?
Comment 15 Joe Drew (not getting mail) 2012-12-04 14:47:18 PST
Created attachment 688481 [details]
testcase for non-simple images
Comment 16 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-04 14:59:45 PST
(In reply to Joe Drew (:JOEDREW! \o/) from comment #13)
> This does seem to work, but it seems that it's incompatible with what
> DrawToPixelSnapped does, so if you make your test images more complex, the
> seam reappears (like: http://i.imgur.com/luNJk.png)

You're absolutely right, by the way. A different fix is needed.
Comment 17 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-04 15:34:41 PST
Created attachment 688502 [details] [diff] [review]
fix v2
Comment 18 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-04 15:54:23 PST
https://tbpl.mozilla.org/?tree=Try&rev=f494bb64a368
Comment 19 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-07 02:55:29 PST
Created attachment 689642 [details] [diff] [review]
fix v3

For the not-all-same-color case this actually doesn't seem to work on Mac :-(. I'm not sure what the problem is there.
Comment 20 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-12 18:38:31 PST
I found a bug and fixed it, which fixed the Mac failure. Let's see how this goes.

https://tbpl.mozilla.org/?tree=Try&rev=3768c1a95a90
Comment 21 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-13 02:11:00 PST
OK, there are new failures...
Comment 22 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-20 02:12:40 PST
The problem I fixed for Mac is that when we snap the fill rect, we also need to adjust the dest rect (the rect filled by a single tile) to match, by applying the same transform to the dest rect that we used to snap the fill rect. If we don't do this, then for example if the dest rect and the fill rect were originally the same, after snapping the dest rect might not exactly fill the fill rect and we get a visible seam along the edge.

But this is the cause of the new failures. It means that changes to the fill rect that would normally be invisible (e.g. because we're only changing to include or exclude pixels under the solid border of the element) cause visible changes in the rendering, because a slight scale is applied to the transform.
Comment 23 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-20 02:55:06 PST
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #22)
> The problem I fixed for Mac is that when we snap the fill rect, we also need
> to adjust the dest rect (the rect filled by a single tile) to match, by
> applying the same transform to the dest rect that we used to snap the fill
> rect. If we don't do this, then for example if the dest rect and the fill
> rect were originally the same, after snapping the dest rect might not
> exactly fill the fill rect and we get a visible seam along the edge.

Actually, this shouldn't happen. It only happens on Mac because Mac doesn't do clamping properly :-(.
Comment 24 Joe Drew (not getting mail) 2012-12-20 08:19:49 PST
Is that because we default to EXTEND_NONE?
Comment 25 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-20 19:50:44 PST
PreparePatternForUntiledDrawing suggests we're setting EXTEND_PAD. But last I checked, cairo-quartz doesn't support EXTEND_PAD.
Comment 26 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-12-20 20:01:20 PST
Assuming it is the EXTEND_PAD problem, I think I'll go ahead with this patch as-is and disable the test on Mac. This bug won't be fixed on Mac but I'm not sure how to fix it without working EXTEND_PAD :-(.
Comment 27 Robert O'Callahan (:roc) (email my personal email if necessary) 2013-01-02 23:35:33 PST
Created attachment 697349 [details] [diff] [review]
fix v4

This patch fixes the bug for single-color images, and for non-Mac platforms. The bug can still occur on Mac because we don't support EXTEND_PAD with Quartz; that's bug 567370.
Comment 28 Joe Drew (not getting mail) 2013-01-03 09:15:36 PST
Comment on attachment 697349 [details] [diff] [review]
fix v4

Review of attachment 697349 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/base/nsLayoutUtils.cpp
@@ +3830,5 @@
> +  // Snap even if we have a scale in the context. But don't snap if
> +  // we have something that's not translation+scale, or if the scale flips in
> +  // the X or Y direction, because snapped image drawing can't handle that yet.
> +  if (!currentMatrix.HasNonAxisAlignedTransform() &&
> +      currentMatrix.xx > 0.0 && currentMatrix.yy > 0.0 &&

I wonder if this line is something that we could use in general on gfxMatrix - HasFlip() or something. *shrug*
Comment 29 Robert O'Callahan (:roc) (email my personal email if necessary) 2013-01-06 21:48:00 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/546f9f3999d3
Comment 30 Ed Morley [:emorley] 2013-01-07 08:24:47 PST
https://hg.mozilla.org/mozilla-central/rev/546f9f3999d3
Comment 31 Cork 2013-02-20 10:10:40 PST
*** Bug 842968 has been marked as a duplicate of this bug. ***

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