"-moz-transform: scale" draws seams between tiled images

RESOLVED FIXED in mozilla20

Status

()

Core
Layout: View Rendering
RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: Alexander Maryanovsky, Assigned: roc)

Tracking

unspecified
mozilla20
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 4 obsolete attachments)

(Reporter)

Description

8 years ago
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

8 years ago
here one more example:

http://lamp2.fhstp.ac.at/~lbz/beispiele/ws2009/firefox/

Comment 2

7 years ago
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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

5 years ago
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

5 years ago
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

5 years ago
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

5 years ago
Bump. This would be great to fix. Image tiling libraries aren't very useful in FF.
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!
Created attachment 688065 [details]
simplified testcase based on comment #6
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.
Assignee: nobody → roc
Attachment #688070 - Flags: review?(joe)
Created attachment 688072 [details] [diff] [review]
fix

Updated patch
Attachment #688070 - Attachment is obsolete: true
Attachment #688070 - Flags: review?(joe)
Attachment #688072 - Flags: review?(joe)

Comment 12

5 years ago
Awesome! Thank you for your work on this one Robert :-)
Anything else I can do to help, just shout out.
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.
Attachment #688072 - Flags: review?(joe) → review-
(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?
Created attachment 688481 [details]
testcase for non-simple images
Attachment #688481 - Attachment mime type: text/plain → text/html
(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.
Created attachment 688502 [details] [diff] [review]
fix v2
Attachment #688072 - Attachment is obsolete: true
Attachment #688502 - Flags: review?(joe)
https://tbpl.mozilla.org/?tree=Try&rev=f494bb64a368
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.
Attachment #688502 - Attachment is obsolete: true
Attachment #688502 - Flags: review?(joe)
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
OK, there are new failures...
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.
(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 :-(.
Is that because we default to EXTEND_NONE?
PreparePatternForUntiledDrawing suggests we're setting EXTEND_PAD. But last I checked, cairo-quartz doesn't support EXTEND_PAD.
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 :-(.
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.
Attachment #689642 - Attachment is obsolete: true
Attachment #697349 - Flags: review?(joe)
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*
Attachment #697349 - Flags: review?(joe) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/546f9f3999d3
https://hg.mozilla.org/mozilla-central/rev/546f9f3999d3
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20

Updated

4 years ago
Duplicate of this bug: 842968
Depends on: 862323

Updated

4 years ago
Depends on: 865546

Updated

4 years ago
Depends on: 896249
You need to log in before you can comment on or make changes to this bug.