Join GitHub today
4-Connected Line Drawing #2336
This adds 4-connected line drawing capability.
The API is "broken" in the sense that the line drawing subroutine now takes and pays attention to a potential
In terms of the API, it seemed as though the choice were
This PR should probably either be closed or given the "2.0" label.
Also, while typing this PR I realized that it does not solve the vector rasterization problem for which it was intended because the line drawing code snaps line endpoints to the centers of pixels before drawing; because of that, the reported pixels are not guaranteed to cover the line. The picture below has an example.
The blue line is the original with the tiles that should be reported. The red is the snapped-to-centers line with the tiles that will be reported. Since there are some tiles in the blue set that are not in the red set, this cannot be used. (If the set of tiles is 3x3 but the set of pixels is 3nx3n, then there will be some pixels which should be drawn but which are not because there is no tile to contain them.)
I did not change endpoint-snapping behavior because seems like an even larger change than the one presented here, so the three-part list above applies. I am planning to put in a solution to the original problem that does not involve the line rasterizer.
Note: I said above that it appears from the code that the line endpoints are being snapped to the centers of the pixels. Even if that is not correct -- if they are being snapped to a corner or the middle of an edge -- the fact that the endpoints are being converted to integers means that such an example can probably still be constructed.
Okay, I will rework the interface.