RESOLVED FIXED Bug 25619
the shadow direction is negated in canvas context shadowOffsetY.
https://bugs.webkit.org/show_bug.cgi?id=25619
Summary the shadow direction is negated in canvas context shadowOffsetY.
Yongjun Zhang
Reported 2009-05-07 10:48:37 PDT
The shadow is painted on the wrong direction when shadowOffsetY is set. For example, for context.shadowOffsetY = 5, the shadow is painted 5 pix _above_ , not 5 px _below_ the shadowed object. However, if context.shadowBlur is set, the shadow is painted correctly.
Attachments
a simple test case. (514 bytes, text/html)
2009-05-07 10:50 PDT, Yongjun Zhang
no flags
use the right y offset value for simple shadowed text. (1.69 KB, patch)
2009-05-07 11:04 PDT, Yongjun Zhang
no flags
Patch (3.66 KB, patch)
2010-12-21 08:49 PST, Mihai Parparita
no flags
Patch (7.54 KB, patch)
2010-12-21 13:59 PST, Mihai Parparita
no flags
Patch (11.64 KB, patch)
2010-12-21 15:41 PST, Mihai Parparita
no flags
Patch for landing (11.69 KB, patch)
2010-12-22 18:17 PST, Mihai Parparita
no flags
Yongjun Zhang
Comment 1 2009-05-07 10:50:13 PDT
Created attachment 30103 [details] a simple test case.
Yongjun Zhang
Comment 2 2009-05-07 10:57:56 PDT
looks like simple shadowed text are painted differently than blur-shadowed text. Blur-shadowed text is painted directly by the CG; while simple shadow is painted in FontMac.mm by offsetting the text position (line 105).
Yongjun Zhang
Comment 3 2009-05-07 11:04:45 PDT
Created attachment 30104 [details] use the right y offset value for simple shadowed text.
Simon Fraser (smfr)
Comment 4 2009-05-14 22:00:31 PDT
Comment on attachment 30104 [details] use the right y offset value for simple shadowed text. This breaks CSS text-shadow when the blur radius is 0.
Yongjun Zhang
Comment 5 2009-05-18 10:43:23 PDT
yes, indeed it breaks CSS text-shadow without blur radius. I'll keep digging :)
Mihai Parparita
Comment 6 2010-12-21 08:49:57 PST
Mihai Parparita
Comment 7 2010-12-21 08:51:09 PST
The attached patch seems to work for both canvas and CSS text shadows. Is checking for shadowsIgnoreTransforms the right thing? If so, I'll add a layout test and clean this up for review.
Mihai Parparita
Comment 8 2010-12-21 13:59:22 PST
Mihai Parparita
Comment 9 2010-12-21 15:41:44 PST
Mihai Parparita
Comment 10 2010-12-21 15:48:19 PST
New version of the patch fixes things for transforms too (it actually sends that on the CG shadow path, since making shadow offsets not take into account transforms was too complex for the simple path). Note that that was a problem before this patch too, on my test case at http://persistent.info/webkit/test-cases/webkit-25619.html the shadow in the top right is not only above (it should be below), it's also displaced by twice as much as it should be (there's a 2x scale transform on the canvas).
Simon Fraser (smfr)
Comment 11 2010-12-22 17:15:10 PST
Comment on attachment 77160 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=77160&action=review > WebCore/platform/graphics/mac/FontMac.mm:183 > + // If shadows are ignoring transforms, then we haven't applied the Y coordinate flip yet, so down is negative. You never enter this code if shadows ignore transforms, because of the !context->shadowsIgnoreTransforms() check above. So this comment is not accurate.
Mihai Parparita
Comment 12 2010-12-22 17:18:21 PST
Comment on attachment 77160 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=77160&action=review >> WebCore/platform/graphics/mac/FontMac.mm:183 >> + // If shadows are ignoring transforms, then we haven't applied the Y coordinate flip yet, so down is negative. > > You never enter this code if shadows ignore transforms, because of the !context->shadowsIgnoreTransforms() check above. So this comment is not accurate. The check is "!context->shadowsIgnoreTransforms() || context->getCTM().isIdentityOrTranslationOrFlipped()", so we'll still end up here if the canvas transform is just a translation (or non-existent).
WebKit Commit Bot
Comment 13 2010-12-22 18:07:09 PST
Comment on attachment 77160 [details] Patch Rejecting attachment 77160 [details] from commit-queue. Failed to run "['./Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=eseidel-cq-sf', 'apply-attachment', '--no-update', '--non-interactive', 77160]" exit_code: 2 Last 500 characters of output: le WebCore/platform/graphics/GraphicsContext.h Hunk #1 succeeded at 242 (offset 2 lines). patching file WebCore/platform/graphics/mac/FontMac.mm Hunk #1 FAILED at 172. 1 out of 1 hunk FAILED -- saving rejects to file WebCore/platform/graphics/mac/FontMac.mm.rej patching file WebCore/platform/graphics/win/FontCGWin.cpp Hunk #1 succeeded at 357 with fuzz 2 (offset 3 lines). Failed to run "[u'/Projects/CommitQueue/Tools/Scripts/svn-apply', u'--reviewer', u'Simon Fraser', u'--force']" exit_code: 1 Full output: http://queues.webkit.org/results/7317088
Mihai Parparita
Comment 14 2010-12-22 18:17:37 PST
Created attachment 77290 [details] Patch for landing
WebKit Commit Bot
Comment 15 2010-12-22 19:24:16 PST
The commit-queue encountered the following flaky tests while processing attachment 77290 [details]: inspector/styles-disable-then-enable.html bug 51384 (author: pfeldman@chromium.org) The commit-queue is continuing to process your patch.
WebKit Commit Bot
Comment 16 2010-12-22 19:25:51 PST
Comment on attachment 77290 [details] Patch for landing Clearing flags on attachment: 77290 Committed r74532: <http://trac.webkit.org/changeset/74532>
WebKit Commit Bot
Comment 17 2010-12-22 19:26:00 PST
All reviewed patches have been landed. Closing bug.
WebKit Review Bot
Comment 18 2010-12-22 20:24:50 PST
http://trac.webkit.org/changeset/74532 might have broken SnowLeopard Intel Release (Tests) The following tests are not passing: http/tests/local/stylesheet-and-script-load-order-media-print.html
Mihai Parparita
Comment 19 2010-12-22 21:32:23 PST
(In reply to comment #18) > http://trac.webkit.org/changeset/74532 might have broken SnowLeopard Intel Release (Tests) > The following tests are not passing: > http/tests/local/stylesheet-and-script-load-order-media-print.html This is just a flaky test, the bot is green again. Bug 51470 is already filed for it.
Note You need to log in before you can comment on or make changes to this bug.