|Summary:||[GTK] fast/canvas/DrawImageSinglePixelStretch.html fails|
|Product:||WebKit||Reporter:||Philippe Normand <pnormand>|
|Component:||Canvas||Assignee:||Martin Robinson <mrobinson>|
|Severity:||Normal||CC:||d-r, krit, leandro, mdelaney7, mrobinson, nishant.646, nishant.bansal, rakuco, webkit.review.bot, zan|
|Version:||528+ (Nightly build)|
|OS:||OS X 10.5|
Description Philippe Normand 2011-04-12 02:15:55 PDT
The color inside the rectangle is not uniform, it's more like a gradient. Will skip for now.
Comment 1 Matthew Delaney 2011-04-12 11:39:19 PDT
Yea, that's the incorrect behavior you're seeing then. It does show a 'FAILED', correct? I've interpreted this portion of the spec as the inspiration for this test: "If the original image data is a bitmap image, the value painted at a point in the destination rectangle is computed by filtering the original image data. The user agent may use any filtering algorithm (for example bilinear interpolation or nearest-neighbor). When the filtering algorithm requires a pixel value from outside the original image data, it must instead use the value from the nearest edge pixel. (That is, the filter uses 'clamp-to-edge' behavior.)" It also came to my attention that many rendering platforms don't usually do this behavior of clamp to edge because it's not desired in cases where tiling of an image happens and such. Though, the pixels can be first copied into a buffer image and then drawn to effectively create the clamp to edge behavior.
Comment 2 Nishant Bansal 2013-02-20 23:38:27 PST
The same issue is also present in EFL port.
Comment 3 Dirk Schulze 2013-02-21 08:50:53 PST
Can you upload and expected and actual image for comparison please?
Comment 5 Martin Robinson 2013-02-21 17:09:21 PST
(In reply to comment #3) > Can you upload and expected and actual image for comparison please? The test is a text dump, but with a bit of tinkering I was able to see the canvas. It's clear that the issue is that we are sampling outside the source rectangle. I've uploaded a patch fixing the issue.
Comment 6 Nishant Bansal 2013-02-22 04:12:16 PST
I tried this patch. The issue is still present in EFL port.
Comment 7 Martin Robinson 2013-02-22 07:54:44 PST
(In reply to comment #6) > I tried this patch. The issue is still present in EFL port. What version of Cairo? Also, are you using a backend other than image?
Comment 8 Nishant Bansal 2013-02-25 03:20:54 PST
(In reply to comment #7) > (In reply to comment #6) > > I tried this patch. The issue is still present in EFL port. > > What version of Cairo? Also, are you using a backend other than image? cairo version is 1.12.4. I didn't understand your second query.
Comment 9 Nishant Bansal 2013-02-25 21:20:12 PST
There was some build problem or something. I tried this patch on the latest webkit and it worked fine.
Comment 10 Martin Robinson 2013-02-25 23:05:05 PST
(In reply to comment #9) > There was some build problem or something. I tried this patch on the latest webkit and it worked fine. Thanks for the information. Dirk, maybe you would be willing to review this patch?
Comment 11 Alejandro G. Castro 2013-04-11 17:15:06 PDT
Comment on attachment 189642 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=189642&action=review LGTM! > Source/WebCore/platform/graphics/cairo/PlatformContextCairo.cpp:196 > + // The pattern transformation properly scales the pattern for when the source rectangle is a Nit, "for when" -> "when"
Comment 12 Martin Robinson 2013-04-18 09:18:50 PDT
Comment on attachment 189642 [details] Patch Clearing flags on attachment: 189642 Committed r148681: <http://trac.webkit.org/changeset/148681>
Comment 13 Martin Robinson 2013-04-18 09:18:55 PDT
All reviewed patches have been landed. Closing bug.