Also adding pixelSnappedLocation/Size to Int/FractionalLayoutRect.
Created attachment 133476 [details] Patch
Comment on attachment 133476 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=133476&action=review OK. > Source/WebCore/rendering/RenderListMarker.cpp:1124 > + marker.moveBy(roundedIntPoint(boxOrigin)); I thought we had new fancy .round() methods? > Source/WebCore/rendering/RenderListMarker.cpp:1263 > + marker.moveBy(IntPoint(roundToInt(box.x()), roundToInt(box.y() - logicalHeight()))); making a LayoutPoint and rounding that seems easier...
Comment on attachment 133476 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=133476&action=review >> Source/WebCore/rendering/RenderListMarker.cpp:1124 >> + marker.moveBy(roundedIntPoint(boxOrigin)); > > I thought we had new fancy .round() methods? We do have these on rects, but not on points. We actually don't have a .pixelSnap() method on rects either, just convenience functions to return pixel snapped values for the location, size, and edges. If you feel like that would be cleaner I'm happy to take a pass through this implementing that.
I think that .round(), .floor(), ciel(), etc. are better than free funcxtions. But I also think we just need to get your branch landed and we can iterate from there. :)
(In reply to comment #4) > I think that .round(), .floor(), ciel(), etc. are better than free funcxtions. But I also think we just need to get your branch landed and we can iterate from there. :) We do have all those on LayoutUnits... the pain is that we still use integers on trunk. I think you were right that this all would have been a lot easier if we'd first moved to a IntegerLayoutUnit abstraction. Anyways, I'm definitely here to volunteer for clean-up once the switch is flipped! Thanks for your diligent reviewing!!
Comment on attachment 133476 [details] Patch Clearing flags on attachment: 133476 Committed r112238: <http://trac.webkit.org/changeset/112238>
All reviewed patches have been landed. Closing bug.