Bug 15720 – [Transforms] Pixel cracks in scaled border-image

• Component: Layout and Rendering
• Status: NEW

Applying non-power-of-2 scaling to a box with border-image results in gross misalignment of the pieces of the border. In the attached test case, move the slider to see the effect.

Created attachment 16896 [details]
Test case

*** Bug 39500 has been marked as a duplicate of this bug. ***

<rdar://problem/7994266>

[Damian Kaleta]

Created attachment 56917 [details]
Propose patch

[WebKit Review Bot]

Attachment 56917 [details] did not pass style-queue:

Failed to run "['WebKitTools/Scripts/check-webkit-style', '--no-squash']" exit_code: 1
WebCore/ChangeLog:6:  Line contains tab character.  [whitespace/tab] [5]
Total errors found: 1 in 4 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Damian Kaleta]

Created attachment 56920 [details]
Propose patch

Fixes tab typo.

[Beth Dakin]

Comment on attachment 56920 [details]
Propose patch

I don't like the idea of GraphicsContext having two new implementations of drawTiledImage() that are copies of the existing implementations except that they take FloatRects instead of IntRects. That is a lot of code duplication, which is something we try to avoid. The GraphicsContext::drawImage() functions do a better job of sharing code. I suggest taking a look at them and devising a way to share as much code as possible.

Also, right now we only call roundToDevicePixels() from graphics-centric code…in other words, this would be the first patch where we called into that function directly from the render tree. I wonder if that is a separation that we want to maintain or not. It might be worth considering having drawTiledImage() call roundToDevicePixels() on the FloatRect rather than doing that at the call sites. 

I would be interested to see if Hyatt, Dan, or Darin has an opinion too :-)

[Damian Kaleta]

Created attachment 57389 [details]
Proposed patch.

[Beth Dakin]

Comment on attachment 57389 [details]
Proposed patch.

r=me

[WebKit Review Bot]

http://trac.webkit.org/changeset/60642 might have broken GTK Linux 32-bit Release

[James Robinson]

Hi.  This changed the rendering of fast/borders/border-image-rotate-transform.html on the chromium bots and I think it may be a regression.  Here's the expected rendering:

http://trac.webkit.org/export/60645/trunk/LayoutTests/platform/mac/fast/borders/border-image-rotate-transform-expected.png

and here's what we are getting:

http://build.chromium.org/buildbot/layout_test_results/webkit-rel-mac-webkit-org/results/layout-test-results/fast/borders/border-image-rotate-transform-actual.png

The B B B and R R R borders are at a different offset after the patch.  If this is intended, could you update the platform/mac expected results?

(In reply to comment #11)
> Hi.  This changed the rendering of fast/borders/border-image-rotate-transform.html on the chromium bots and I think it may be a regression.

It’s a regression.

[James Robinson]

Thanks for looking at it.  Given that it's a rendering regression I'm inclined to roll it out.

[James Robinson]

rolled out: http://trac.webkit.org/changeset/60649

[Eric Seidel (no email)]

Borked the gtk.

[Eric Seidel (no email)]

(I was mistaken with my Gtk comment.)

[Eric Seidel (no email)]

Comment on attachment 57389 [details]
Proposed patch.

nm.  Should be r-'d since it was rolled out.

[Mike Taylor]

I believe I'm running into this bug with -webkit-transform:translate(-50%, -50%) on a div with border-image in r100547. Removing the transform gets rid of the "crack" and blurriness. Same in Chrome Canary too.

see http://miketaylr.com/post/338660f5.png

[Radar WebKit Bug Importer]

<rdar://problem/15419921>