Bug 76137 - Borders and box masks behave incorrectly with overlapping offsets
Summary: Borders and box masks behave incorrectly with overlapping offsets
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Simon Fraser (smfr)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-11 18:35 PST by Ian Henderson
Modified: 2012-01-16 14:22 PST (History)
5 users (show)

See Also:


Attachments
test case (2.35 KB, text/html)
2012-01-11 18:35 PST, Ian Henderson
no flags Details
Patch (21.91 KB, text/plain)
2012-01-12 12:24 PST, Simon Fraser (smfr)
webkit.review.bot: commit-queue-
Details
Patch to fix mask-box-image behavior with large slices (12.16 KB, patch)
2012-01-12 14:42 PST, Simon Fraser (smfr)
dino: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Henderson 2012-01-11 18:35:49 PST
Created attachment 122147 [details]
test case

See attached test case.  An 8x8 image is used as a box mask and a border image.  The test case includes three offsets to divide the image into nine parts -- 3, 4, and 5.  The rendering is incorrect in the 4 and 5 cases (though it may not appear so in the box mask case -- the untouched areas are left unclipped unless we fall into the transparency layer path by e.g. pinch zooming).

It seems like we should do what it says at <http://www.w3.org/TR/css3-background/#border-image-width>:
If two opposite ‘border-image-width’ offsets are large enough that they overlap, then the used values of all ‘border-image-width’ offsets are proportionally reduced until they no longer overlap. In mathematical notation: Given Lwidth as the width of the border image area, Lheight as its height, and Wside as the border image width offset for the side side, let f = min(Lwidth/(Wleft+Wright), Lheight/(Wtop+Wbottom)). If f < 1, then all W are reduced by multiplying them by f.
Comment 1 Ian Henderson 2012-01-11 20:22:44 PST
(In reply to comment #0)
> It seems like we should do what it says at <http://www.w3.org/TR/css3-background/#border-image-width>:
> If two opposite ‘border-image-width’ offsets are large enough that they overlap, then the used values of all ‘border-image-width’ offsets are proportionally reduced until they no longer overlap. In mathematical notation: Given Lwidth as the width of the border image area, Lheight as its height, and Wside as the border image width offset for the side side, let f = min(Lwidth/(Wleft+Wright), Lheight/(Wtop+Wbottom)). If f < 1, then all W are reduced by multiplying them by f.

Looking at the code, we already make this correction, but it's not enough to ensure there's at least one pixel in the middle to stretch.
Comment 2 Simon Fraser (smfr) 2012-01-12 10:59:04 PST
Debug builds assert when zooming with the testcase:

ASSERTION FAILED: CGImageGetHeight(image.get()) == currHeight - CGRectIntegral(srcRect).origin.y
/Volumes/SSData/Development/OSX/webkit/OpenSource/Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp(197) : void WebCore::GraphicsContext::drawNativeImage(NativeImagePtr, const WebCore::FloatSize &, WebCore::ColorSpace, const WebCore::FloatRect &, const WebCore::FloatRect &, WebCore::CompositeOperator)
1   0x10422a238 WebCore::GraphicsContext::drawNativeImage(CGImage*, WebCore::FloatSize const&, WebCore::ColorSpace, WebCore::FloatRect const&, WebCore::FloatRect const&, WebCore::CompositeOperator)
Comment 3 Simon Fraser (smfr) 2012-01-12 11:28:12 PST
Isn't the relevant spec text actually:
"The regions given by the ‘border-image-slice’ values may overlap. However if the sum of the right and left widths is equal to or greater than the width of the image, the images for the top and bottom edge and the middle part are empty, which has the same effect as if a nonempty transparent image had been specified for those parts. Analogously for the top and bottom values."
Comment 4 Simon Fraser (smfr) 2012-01-12 12:24:08 PST
Created attachment 122288 [details]
Patch
Comment 5 Simon Fraser (smfr) 2012-01-12 12:24:48 PST
Will investigate issues with border-image-width separately.
Comment 6 WebKit Review Bot 2012-01-12 13:02:53 PST
Comment on attachment 122288 [details]
Patch

Attachment 122288 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11227168

New failing tests:
animations/cross-fade-webkit-mask-box-image.html
fast/borders/border-image-slice-constrained.html
Comment 7 Dave Hyatt 2012-01-12 13:07:33 PST
Comment on attachment 122288 [details]
Patch

r=me
Comment 8 Simon Fraser (smfr) 2012-01-12 13:26:17 PST
Comment on attachment 122288 [details]
Patch

http://trac.webkit.org/changeset/104851
Keeping bug open to look at border-image-width behavior.
Comment 9 Simon Fraser (smfr) 2012-01-12 14:42:26 PST
Created attachment 122313 [details]
Patch to fix mask-box-image behavior with large slices
Comment 10 WebKit Review Bot 2012-01-12 15:15:54 PST
Comment on attachment 122313 [details]
Patch to fix mask-box-image behavior with large slices

Attachment 122313 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11115617

New failing tests:
fast/backgrounds/mask-box-image.html
Comment 11 Simon Fraser (smfr) 2012-01-16 14:22:27 PST
http://trac.webkit.org/changeset/105091