Skip to content
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

Correctly compute ultra-zoomed line paths [fixes #217] #353

Merged
merged 2 commits into from
Mar 28, 2016

Conversation

etpinard
Copy link
Contributor

@alexcjohnson @mdtusz

Issue #217 is two months old now and after numerous attempts at fixing it the right way by adding more complexity to the already-complex line decimation algorithm, I gave up.

This PR removes the clip-multiple constrain in the linear to pixel convert routine. This has three effects:

  1. Ultra-zoomed line paths (where 4 segment pts are beyond the clip-multiple constrain) are now computed correctly, fixing Line paths are not correctly computed when their points are well-beyond the axis ranges #217.
  2. Far-off-edge points now have coordinates of very large magnitude that some browser's svg renderers may not understand. Note: I couldn't find any documentation on the svg limits.
  3. The line decimation algorithm is slowed down as now far-off-edge points are not de facto clusters anymore.

I decided to make this PR because I thought that fixing #217 was more important than side-effects 2. and 3. above. I hope you agree.

- so that line paths in extreme zoomed in axis ranges are computed
  correctly.
- this patch may: make far-off-edge pts have coords that svg
  doesn’t understand
- this patch may slow down the line decimation algorithm (as far-off-edge
  pts used to be consisdered the same previously)
@@ -0,0 +1,45 @@
{
"data": [
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this mock looks like:

image

on master.

@mdtusz
Copy link
Contributor

mdtusz commented Mar 25, 2016

I did some researching on this before as well and came to the same conclusions (unless we were to implement a much more complex truncate-at-the-plot-borders line decimation method). I couldn't find anything on maximal svg values either - I would think that svg rendering can accomodate arbitrarily large numbers and interpolate what to render if a coordinate lies outside those bounds.

In any case, if we do encounter issues with this, it will be easy enough to revert to the old solution, or create a more robust one instead.

💃

@alexcjohnson
Copy link
Collaborator

Sure. Actually it seems like the way getTolerance is implemented, the points will continue to get sparser and sparser as they get farther away, so it's likely this won't have too much effect on performance anyway. 💃

@alexcjohnson
Copy link
Collaborator

At some point it may be worthwhile to look into making getTolerance more aggressive (superlinear in distance from the viewport, perhaps, at least to a point) but this will need some heavy testing to make sure it doesn't introduce new failure modes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants