Closed Bug 504071 Opened 15 years ago Closed 12 years ago

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

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla20

People

(Reporter: msasha, Assigned: roc)

References

(
URL
)

Details

Attachments

(3 files, 4 obsolete files)

simplified testcase based on comment #6
(deleted), text/html
Details
testcase for non-simple images
(deleted), text/html
Details
fix v4
(deleted), patch
joe
: review+
Details | Diff | Splinter Review
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.
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
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
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>
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
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!
Attached patch fix (obsolete) (deleted) — — Splinter Review
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)
Attached patch fix (obsolete) (deleted) — — Splinter Review
Updated patch
Attachment #688070 - Attachment is obsolete: true
Attachment #688070 - Flags: review?(joe)
Attachment #688072 - Flags: review?(joe)
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?
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.
Attached patch fix v2 (obsolete) (deleted) — — Splinter Review
Attachment #688072 - Attachment is obsolete: true
Attachment #688502 - Flags: review?(joe)
Attached patch fix v3 (obsolete) (deleted) — — Splinter Review
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 :-(.
Attached patch fix v4 (deleted) — — Splinter Review
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/mozilla-central/rev/546f9f3999d3
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Depends on: 862323
Depends on: 865546
Depends on: 896249
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: