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

when zooming in, there should be no need to mark all nodes as hidden #117

Open
wonder-mice opened this issue Sep 28, 2018 · 6 comments
Open

Comments

@wonder-mice
Copy link

I noticed that d3-flame-graph casually traverses the entire data structure for different reasons. This makes many operations slower than it would be desired.

Specifically, when zooming in, it should be enough to mark nodes on the same level as zoomed node as hidden and when such flag is set, return null from getChildren().

@spiermar spiermar added the enhancement New feature or request label Sep 28, 2018
@spiermar
Copy link
Owner

Possibly, feel free to submit a PR. :)

@spiermar spiermar changed the title When zooming in, there should be no need to mark all nodes as hidden when zooming in, there should be no need to mark all nodes as hidden Sep 28, 2018
@wonder-mice
Copy link
Author

Btw, what are the benefits of using d3? I though the idea is to handle large data sets with ease, but all d3 examples I'm looking at are super slow even on small data sets. E.g. if I just create divs for each node manually, will it be better or worse?

@spiermar
Copy link
Owner

Bit more complicated than that I believe, but sure, there are other options that might perform better in certain cases, just a lot more heavy lifting to be done.

@wonder-mice
Copy link
Author

That's exactly what I'm curious about. What this heavy lifting is and how heavy is it. I know that from outside every project/code looks trivial and simple, so I'm trying to understand what I'm missing.

@wonder-mice
Copy link
Author

Is there particular reason why hide and fade are injected into data items instead of d3 nodes? It'll be faster to access them in nodes and allows less conflicts with provided data json format (which can be anything if we'll go with custom getValue, getDelta, getChildren callbacks).

@spiermar
Copy link
Owner

No particular reason.

@spiermar spiermar added this to the 3.0 milestone Oct 23, 2018
@spiermar spiermar self-assigned this Oct 23, 2018
@spiermar spiermar removed this from the 3.0 milestone Oct 12, 2021
@spiermar spiermar removed the enhancement New feature or request label Oct 12, 2021
@spiermar spiermar removed their assignment Oct 12, 2021
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

No branches or pull requests

2 participants