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

Plot.image render SVG elements #1861

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

mkfreeman
Copy link
Contributor

I've found that rendering <svg> elements - specifically those made using plot - can be a powerful visualization technique (example). This is a first pass at supporting svg rendering through the Plot.image mark.

Unsure if this is a desired feature or approach, but figured I could start the conversation.

Copy link
Member

@mbostock mbostock left a comment

Choose a reason for hiding this comment

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

Maybe we could approach this as a Plot.svg mark? I don’t think we want to serialize the generated SVG as a data URL; that’s a lot slower than embedding the SVG directly. You can almost do this as-is with just a bare render function, but presumably we want more flexibility to position (and resize) that element within the frame.

The harder point is that this is a “decoration” mark without data, like the frame mark, rather than a data-driven mark. Not sure how much we want to recommend this pattern vs. something more specific, like a sparkline (similar to a custom symbol with the dot mark).

Edit: The latter comment was a response to the test. The notebook demonstrates the data-driven case. But for example since the plots are rendered separately, they will not share scales and so it could be hard to use correctly.

@mkfreeman
Copy link
Contributor Author

Thanks for your thoughts! I definitely imagine this as a data-driven mark, as in the notebook (sorry the test wasn't more representative of the use-case).

Great point that this may nudge users into a bit of an anti-pattern where they're rendering plots with different scales and showing them together.

In some cases, users may not be concerned with a shared scale across plots (for example, drawing country outlines):
Screenshot 2023-09-14 at 3 38 48 PM

I'll think a little more about how (if) a mark like Plot.svg could behave (or be described) in a more generalizable way. Will also look at the rendering.

@mbostock
Copy link
Member

I like the idea of subplots or “subfacets” that share scales but can be positioned arbitrarily in x and y.

@mkfreeman
Copy link
Contributor Author

Interesting - definitely a bit of a larger undertaking 😭 , will think about it!

@Fil
Copy link
Contributor

Fil commented Sep 15, 2023

@mbostock
Copy link
Member

Yes, but with shared scales. I think it would be a similar mechanism to how facets currently work, with the difference being that you can position the facet arbitrarily in the main plot’s x and y coordinate space, and then the subplots have their own x and y scales (shared across subplots).

@mkfreeman
Copy link
Contributor Author

There's also overlap with the desire for custom tips (#1767) - if subplots can be arbitrarily positioned in x/y space, then with a Pointer transform, they could allow for custom tip content.

Enabling the Tip mark to render svg elements (most importantly, Plots) would get most of the functionality here (except for shared scales).

@Fil
Copy link
Contributor

Fil commented Sep 26, 2023

See #1870

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.

None yet

3 participants