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

scattergl issues with opacity and clustering #2374

Closed
alexcjohnson opened this issue Feb 15, 2018 · 3 comments
Closed

scattergl issues with opacity and clustering #2374

alexcjohnson opened this issue Feb 15, 2018 · 3 comments
Assignees
Labels
bug something broken

Comments

@alexcjohnson
Copy link
Collaborator

screen shot 2018-02-15 at 2 13 04 pm

See https://codepen.io/alexcjohnson/pen/OQOMmp - two issues are apparent here:

  • Color and opacity stop being assigned properly after 4K points. Occasional points beyond this get the right color, but most get some random constant. Note that this problem doesn't happen if you remove opacity, see Coloring for markers using scattergl isn't working properly #1909.
  • I asked for 20K points, the clustering algo is removing way too many of them.

cc @dfcreative @etpinard

@alexcjohnson alexcjohnson added the bug something broken label Feb 15, 2018
@dy
Copy link
Contributor

dy commented Feb 15, 2018

  • 20K points was an edge case of detecting pixel size only by width, fixed in gl-vis/regl-scatter2d@9133a03#diff-168726dbe96b3ce427e7fedce31bb0bcL375.
  • 4096 colors limit - that takes a separate effort. We cannot easily increase palette texture size, that linearly affects performance, and for say 4096×4096 colors initial load will be extra ~150ms or more (if not 500ms). As for color quantization - it needs a separate package for efficient decomposing voronoi diagram, as described here. Because basically for every new data point with unknown color we have to find nearest cluster, and making such search for 10k points or more is inefficient.
    • There are solutions to that - storing per-point colors in GPU, but that blows up GPU memory use, since we do not reuse colors from palette and allocate extra 64bits per point (extra 64Mb of memory for 1M points). That is also possible to store opacity values in a separate buffer, that will be extra 8Mb per 1M points.

Is there a sense to postpone 4096 colors issue for a bit @alexcjohnson?

@dy dy mentioned this issue Feb 16, 2018
1 task
@dy
Copy link
Contributor

dy commented Feb 16, 2018

@alexcjohnson should be fixed with #2377
image

@etpinard
Copy link
Contributor

fixed by #2377

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

No branches or pull requests

3 participants