iD.geo.roundCoords drops too much precision on retina

[bhousel]

On retina screens "a pixel is not a pixel is not a pixel" so our use of iD.geo.roundCoords to truncate all the svg pixels to integer values should be reevaluated.

I know that in the past iD.geo.roundCoords has been attributed to significant performance speedup, so I want re-benchmark that and decide what to do. We probably want to round to tenths instead of integers - but not sure whether to do that always or only if HiDPI detected.

e.g.: rounding to integer css pixels makes square buildings look weird while zooming by single mousewheel clicks:

[pnorman]

all the svg pixels to integer values should be reevaluated ... but not sure whether to do that always or only if HiDPI detected

Is there a difference with sub-pixel rendering and anti-aliasing on non-HiDPI devices?

[bhousel]

Is there a difference with sub-pixel rendering and anti-aliasing on non-HiDPI devices?

I did some digging on this today and made this codepen to understand better for myself.
http://codepen.io/bhousel/pen/MaNBbJ

2 triangles drawn with 1px stroke width. The left triangle is drawn with shape-rendering auto (the default). The right is drawn with crispEdges, which is the svg way of saying "not antialiased". We draw everything in iD with auto aliasing, (except for the scale bar, which is drawn with crispEdges). Then I translate these triangles around in 0.1px increments.

The left triangle slides around smoothly, and the right triangle jumps at device pixel boundaries. I have a retina macbook pro with a non-retina secondary monitor. So I when I run this codepen on the non-retina monitor, I see jumps at 1px, and on the retina side, I see several smallish jumps around 0.3px and 0.7px.

The important takeaway is that the loss of precision is very noticeable on both the normal and the HiDPI screens, and we should really to avoid it. Benchmarks next...

[pnorman]

right triangle jumps at device pixel boundaries.

On my Windows 8.1 desktop with conventional monitors and Chrome, I see the straight lines jump, but the angled line continually progress.

If I zoom in to 200% then I see the straight lines moving more frequently, and the anti-aliased version looks smoother without looking blurred. The latter confirms what I already knew from icon design - anti-aliasing can suck with 1px lines.

[bhousel]

Turns out there was a flaw in the original Getting Serious About SVG benchmark code. The fps buffer would fill up to 100 entries, but rather than draining the buffer like a fifo queue, new entries were being pushed/popped from the end of the buffer. (So the original fps measurement was only benchmarking whatever the code did within the first few seconds).

I forked the benchmarking code and replaced pop with shift to make it a more fair fps buffer, and dropped it down to 20 entries so the fps value would settle a bit more quickly.

Here are the very unscientific results, in each case measured after the fps settles around a value:

test	Retina	Non-Retina	comment
Unrounded - numeric	12.8 fps	23.5 fps
Unrounded - stringified	12.3 fps	22.4 fps
Rounded to nearest integer	13.2 fps	25.6 fps	current
Rounded to nearest integer, long coordinates	12.9 fps	23.5 fps
Rounded to nearest tenth	12.8 fps	23.6 fps

So my takeaway from this is that, yes, rounding to integer coordinates does speed things up a little bit (and the speedup is not from having shorter strings in the d attributes), but this speedup is not as much as the 20% originally reported - more like 7%. It's also entirely possible that browsers have gotten better at this in the last 3 years.

Based on this, I'm planning to either round to tenths, or eliminate the rounding completely and see how things look/perform.

[bhousel]

I made a branch this morning with all the sources of rounding removed and I'm really happy with it:

Compared to the original image, everything is much less jumpy - both on the geometry and the imagery tiles:

Performance wise, I can't tell a difference.