Created attachment 130748 [details] demonstration of problem webkitLineDashOffset is sometimes not handled correctly -- or at least, is handled differently from Firefox's mozDashOffset, and I like how mozDashOffset is handled better. The attachment demonstrates the problem. Open it in Firefox 10 to see the desired rendering, then open it in WebKit to compare. I am currently using WebKit r110098. I have only observed the problem when webkitLineDashOffset is negative and its absolute value is greater than the sum of all dash lengths. Uncommenting the commented-out line in the attachment works around the problem by setting webkitLineDashOffset to its modulo.
Created attachment 228507 [details] Patch
Comment on attachment 228507 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=228507&action=review > LayoutTests/ChangeLog:8 > + Test correct rendering of negative offset fot Canvas dash arrays. fot!
Created attachment 228540 [details] Patch for laning
Comment on attachment 228540 [details] Patch for laning Clearing flags on attachment: 228540 Committed r166746: <http://trac.webkit.org/changeset/166746>
All reviewed patches have been landed. Closing bug.
Comment on attachment 228540 [details] Patch for laning View in context: https://bugs.webkit.org/attachment.cgi?id=228540&action=review > Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp:1189 > + for (size_t i = 0; i < dashes.size(); ++i) > + length += static_cast<float>(dashes[i]); New style for loop is better here: for (auto& dash : dashes) length += static_cast<float>(dash); Also wondering why the static_cast<float> is helpful. > Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp:1191 > + dashOffset = fmod(dashOffset, length) + length; Because we use fmod here instead of fmodf, I believe this involves two conversions from float to double and one conversion from double to float. Please change to use fmodf, unless I am mistaken about that.