This is making the Intel Mac Debug bot bad. Let's make add an explicit conversion to calm the bots.
Created attachment 108524 [details] Proposed build fix: add 2 variables with the proper cast.
Comment on attachment 108524 [details] Proposed build fix: add 2 variables with the proper cast. I think m_blurRadius.scale(1 / static_cast<float>(transform.xScale()), 1 / static_cast<float>(transform.yScale())); would be better.
Created attachment 108528 [details] fix 2....
Rather than a cast we could use narrowPrecisionToFloat next time.
We're not consistent about using narrowPrecisionToFloat(). It seems to have little value. narrowPrecisionToCGFloat, on the other hand, has obvious value.
Comment on attachment 108528 [details] fix 2.... Clearing flags on attachment: 108528 Committed r95879: <http://trac.webkit.org/changeset/95879>
All reviewed patches have been landed. Closing bug.
(In reply to comment #5) > We're not consistent about using narrowPrecisionToFloat(). It seems to have little value. It has value in that you can easily see at the call site that it's not some other kind of static_cast, say from int to float. > narrowPrecisionToCGFloat, on the other hand, has obvious value. What value over calling static_cast<CGFloat>? The two situations seem entirely analogous to me.
(In reply to comment #8) > (In reply to comment #5) > > We're not consistent about using narrowPrecisionToFloat(). It seems to have little value. > > It has value in that you can easily see at the call site that it's not some other kind of static_cast, say from int to float. Then we should use it more consistently! > > narrowPrecisionToCGFloat, on the other hand, has obvious value. > > What value over calling static_cast<CGFloat>? The two situations seem entirely analogous to me. Now that I think about it, you're right. I was thinking that it eliminated some float/double confusion.
rdar://10184811