Bug 42706 - -webkit-transform leaves seams between elements on some platforms
Summary: -webkit-transform leaves seams between elements on some platforms
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 27258 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-07-20 15:23 PDT by Nico Weber
Modified: 2013-02-18 04:19 PST (History)
6 users (show)

See Also:


Attachments
repro (892 bytes, text/html)
2010-07-20 15:23 PDT, Nico Weber
no flags Details
patch (2.15 KB, patch)
2010-08-09 17:09 PDT, Nico Weber
no flags Details | Formatted Diff | Diff
Animated testcase (1.24 KB, text/html)
2010-08-20 10:48 PDT, Simon Fraser (smfr)
no flags Details
hacky patch to round clip rect as well (7.57 KB, application/octet-stream)
2010-08-22 21:56 PDT, Nico Weber
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Weber 2010-07-20 15:23:17 PDT
Created attachment 62123 [details]
repro

If you zoom in on maps.google.com in Safari or Chromium/Mac, you see white seems between the tiles while the zoom animation is running.

There are several causes of this. One is that if a page has adjacent images in a container and applies a weird scale factor (like 1.17) to the image's container, seems appear.

See the attached file. On chrome/windows, this is rendered without seams (probably due to skia rendering only at integer coordinates?). In Safari and Chrome/mac, white lines are visible between the images.

OpenGL specs that triangles need to be transformed so that rasterizing adjacent triangles doesn't produce seams. Maybe the css transforms spec needs to spec that too?

( This is part of http://crbug.com/46118 )
Comment 1 Nico Weber 2010-07-20 17:29:59 PDT
Happens only in Safari when hardware acceleration is disabled.
Comment 2 Nico Weber 2010-08-02 17:04:44 PDT
This also happens on maps if you choose a scale factor of e.g. 1.5 in quartz debug.
Comment 3 Nico Weber 2010-08-09 17:09:57 PDT
Created attachment 63957 [details]
patch

Not a final patch, just for discussion.
Comment 4 Nico Weber 2010-08-10 14:16:04 PDT
We might want to do the same thing for clip rects, too.
Comment 5 Simon Fraser (smfr) 2010-08-20 10:26:13 PDT
I think this will cause image jiggles if, say, the scale is animated.
Comment 6 Nico Weber 2010-08-20 10:39:45 PDT
It doesn't produce jiggles that I can see at least. Note that this rounds to _pixels_.
Comment 7 Simon Fraser (smfr) 2010-08-20 10:48:49 PDT
Created attachment 64964 [details]
Animated testcase

Does this show jiggles with the patch when you hover? (On Mac, turn off accel. compositing to test.)
Comment 8 Nico Weber 2010-08-22 21:56:30 PDT
Created attachment 65074 [details]
hacky patch to round clip rect as well

smfr, thanks for the comment. Your attachment shows jiggles with my first patch, because of the clip. If I remove the clip rect, the animation looks smooth and better than the current behavior.

Two possible remedies: Either don't do the pixel-rounding if a clip rect is set or pixel-round the clip rect too. The latter is pretty messy (rought attempt attached with this comment), but removes the jiggles for your test case. I'd vote for not doing the pixel rounding when a clip rect is set. That's almost as easy as the first patch I attached and should work in the majority of cases.

Here are screencasts that compare the current behavior with the behavior from the two patches, with both your attached test and your attached test without clip:


current behavior
no clip: http://screencast.com/t/ZmUwOTA3
clip: http://screencast.com/t/NjdhNjk2


round image and clip rects (new patch, attached with this comment)
no clip: http://screencast.com/t/YmQ5MDlj
clip: http://screencast.com/t/NjhkNjhmZ


round image rect only, keep float clip (first patch)
no clip: http://screencast.com/t/ZjI4ZGEyMGYt
clip: http://screencast.com/t/ZDMzMzRmM


wdyt?
Comment 9 Shane Stephens 2011-06-13 18:11:29 PDT
*** Bug 27258 has been marked as a duplicate of this bug. ***
Comment 10 inbox 2013-02-18 04:19:29 PST
There does seem to be a 1px white space issue on scaled images within chrome.

If you take a look at dragthebag.com in chrome (expanded to the window size) you will see a 1px gap between the tiled images that make up the mall.  I have tried everything to remove this one pixel gap without success.  

If the browser is scaled down this gap disappears.  

Settings inline-block, font-size to 0, various padding, etc... none of them removed this 1 pixel gap.  I could make the margin-left -1px but it mis-aligns other various elements further down the mall.

This problem doesn't exist in Firefox or on the iPad & iPhone.  Really would love for this issue to be solved for Chrome.