-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for "thin lines" bug in all current browsers. #65
base: master
Are you sure you want to change the base?
Conversation
The fix works by applying the translation transform to the whole layer at once, rounding the zoom level to the nearest 1/256th, and of course rounding any translation transforms to the nearest pixel.
Please pull and incorporate this patch. It fixed the "thin-line" issue for a project we were working on! |
Fixed for IE9, but Firefox 8 still showing those damn lines... :-( |
Seems to work fine for me in FF8, do you have an example that exhibits the issue? |
I may have spoken too soon. Your patch is working just fine in FF8 on my home machine. I'll follow up tomorrow if I can reproduce the issue back at work. Thanks for your work on this--you've calmed my OCD. ;-) |
What's the holdup on this patch, and is there anything we can do to help? Polymaps is an excellent mapping framework, and I'm tired of it feeling "cheap" because of this visual glitch. |
Unfortunately while fixing most the "thin lines", I've found that in the latest Firefox I still occasionally see a horizontal line. Still I would like to see this patch incorporated, as it is still an improvement over the stock polymaps. |
I'm still just living with the gaps on all my prototypes for now, but this issue is really a bummer. As you can see in @mbostock's test case this is not Polymaps' fault at all — SVG renderers just don't draw correctly. There's some more good discussion of this on issue #36 as well. I'm torn — it feels so wrong to handle pixel-level scaling math and rounding ourselves when SVG's vector model should take care of that beautifully in theory, but OTOH unless we can get the vendors to care the choices might be: make the code ugly or leave the maps ugly :-( |
I was able to "fix" my problem by overlapping the tiles by 0.5 px (additional to the changes requested in this pull request). @@ -838,8 +843,8 @@
var c = po.map.locationCoordinate(l),
k = Math.pow(2, zoom - c.zoom);
return {
- x: tileSize.x * (k * c.column - column),
- y: tileSize.y * (k * c.row - row)
+ x: (tileSize.x+1) * (k * c.column - column) - 0.5,
+ y: (tileSize.y+1) * (k * c.row - row) - 0.5
};
}
}; |
The fix works by applying the translation transform to the whole layer at once, rounding the zoom level to the nearest 1/256th, and of course rounding any translation transforms to the nearest pixel.
I'm not sure about the effect on transform stacks e.g. rotations and so on, but at least it fixes the problem for the majority of uses.
Please review carefully before merging as I've only tested on a few examples so far.