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>
Created attachment 56917 [details] Propose patch
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.
Created attachment 56920 [details] Propose patch Fixes tab typo.
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 :-)
Created attachment 57389 [details] Proposed patch.
Comment on attachment 57389 [details] Proposed patch. r=me
http://trac.webkit.org/changeset/60642 might have broken GTK Linux 32-bit Release
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.
Thanks for looking at it. Given that it's a rendering regression I'm inclined to roll it out.
rolled out: http://trac.webkit.org/changeset/60649
Borked the gtk.
(I was mistaken with my Gtk comment.)
Comment on attachment 57389 [details] Proposed patch. nm. Should be r-'d since it was rolled out.
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
<rdar://problem/15419921>