improve performant table charts, remove feat flag

[Light2Dark]

📝 Summary

Some of these changes are opinionated so feel free to disagree.

• increase chart width from 70 -> 80
• removes feature flag. This is now the default. Remove legacy vega spec and code.
• string charts <20k rows now show charts
• stats for escaped column names were missing
• very thin bars for temporal columns. changed to even-width bars
• better hover visuals

before:

after:

CleanShot.2025-10-24.at.11.37.56.mp4

When using temporal type, the bar widths are proportioned to the values. this can make some bars have very small widths. The fix is to use ordinal. Additionally, there is better hovering behaviour.

🔍 Description of Changes

📋 Checklist

• I have read the contributor guidelines.
• For large changes, or changes that affect the public API: this change was discussed or approved through an issue, on Discord, or the community discussions (Please provide a link if applicable).
• I have added tests for the changes made.
• I have run the code and verified that it works as expected.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
marimo-docs	Ready	Preview	Comment	Oct 29, 2025 2:14am

[akshayka]

The desired behavior for a histogram is that each bin represents the same range. Is that what is meant by

When using temporal type, the bar widths are proportioned to the values.

and if so, then we shouldn't make this change. But I agree that the plots in the "before" image look ugly.

Can you explain in more detail what the original problem is and how this change fixes it? I don't quite understand.

[akshayka]

@Light2Dark , additionally can you provide a sample notebook (in smoke_tests) where I can look at the before and after behavior?

[Light2Dark]

The desired behavior for a histogram is that each bin represents the same range. Is that what is meant by

When using temporal type, the bar widths are proportioned to the values.

and if so, then we shouldn't make this change. But I agree that the plots in the "before" image look ugly.

Can you explain in more detail what the original problem is and how this change fixes it? I don't quite understand.

I should preface by saying this is a bug when turning on performant_table_charts feature flag. We use temporal type for the chart which causes the bar width to be proportioned to the range. If using ordinal type, the bar widths are the same regardless of the duration they occupy.

I like the proportioned bars idea, but it looks ugly when one bar takes up a lot of space. This alternative, I think simplest and matches non feature flag behaviour. I'm not sure if narwhals v2 has changed anything to offer better alternatives for temporal charting.

will create a sample notebook!

[akshayka]

Thanks so much for the additional context!

I should preface by saying this is a bug when turning on performant_table_charts feature flag.

Got it.

We use temporal type for the chart which causes the bar width to be proportioned to the range. If using ordinal type, the bar widths are the same regardless of the duration they occupy.

I like the proportioned bars idea, but it looks ugly when one bar takes up a lot of space.

For histograms (and anything in our product conveying data / data distributions), we should prioritize correctness over aesthetics; that said I'm happy to look at the sample notebook, that'll make this a lot more concrete for me.

will create a sample notebook!

Thank you!

[Light2Dark]

I created a notebook here: marimo/_smoke_tests/tables/column-header-chart.py Made a decision to increase the chart width but feel free to disagree.

I think we can get this in for the following release (not today)

[akshayka]

I created a notebook here: marimo/_smoke_tests/tables/column-header-chart.py Made a decision to increase the chart width but feel free to disagree.

I think we can get this in for the following release (not today)

Taking a look, thank you for putting this together

[akshayka]

@Light2Dark

I compared 0.17.2, with performant table charts disabled, against this PR. Can you help me understand how performant table charts treat numerical columns when drawing histograms? It seems like the bin width can be variable?

For example, consider the following data:

data = [1, 1, 1, 1, 1, 2, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5, 5, 5, 5, 5,  8, 9, 10] 
df = pl.DataFrame({"data": data})
df

(A) 0.17.2, without performant table charts.

(B) This PR/performant table charts.

It looks like (B) doesn't actually represent the correct data distribution? The 1-2 and 2-3 bars don't like right? When I mouse over the bins, it seems to be because bin widths/whether to include the boundary of a bin is inconsistent in (B), but I'm not sure why?

Before removing the feature flag we should make sure that we don't distort data distributions. In my opinion histograms should always have a single fixed bin width. If I am misunderstanding something please let me know!

[Light2Dark]

Hmm, it shouldn't be inconsistent 🤔. This is the raw bin calculation

[
  "BinValue(bin_start=1, bin_end=2.0, count=6)",
  "BinValue(bin_start=2.0, bin_end=3.0, count=5)",
  "BinValue(bin_start=3.0, bin_end=4.0, count=6)",
  "BinValue(bin_start=4.0, bin_end=5.0, count=8)",
  "BinValue(bin_start=5.0, bin_end=6.0, count=0)",
  "BinValue(bin_start=6.0, bin_end=7.0, count=0)",
  "BinValue(bin_start=7.0, bin_end=8.0, count=1)",
  "BinValue(bin_start=8.0, bin_end=9.0, count=1)",
  "BinValue(bin_start=9.0, bin_end=10.0, count=1)"
]

Looks like narwhals uses left-inclusive, right-inclusive for the first bin (to capture the minimum), and then left-inclusive, right exclusive for the rest. So, 1-2 has six values. But 2-3 doesn't include the last 3 so five values.

python code:

data = [1, 1, 1, 1, 1, 2, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5, 5, 5, 5, 5,  8, 9, 10] 
df = pl.DataFrame({"data": data})

from marimo._plugins.ui._impl.tables.narwhals_table import NarwhalsTableManager

DEFAULT_BIN_SIZE = 9
manager = NarwhalsTableManager.from_dataframe(df)
manager.get_bin_values("data", DEFAULT_BIN_SIZE)

marking as draft because I realize the narwhals hist API is marked unstable

[akshayka]

Looks like narwhals uses left-inclusive, right-inclusive for the first bin (to capture the minimum), and then left-inclusive, right exclusive for the rest. So, 1-2 has six values. But 2-3 doesn't include the last 3 so five values.

Got it, thank you for explaining. That should be okay then, really appreciate the explanation.

marking as draft because I realize the narwhals hist API is marked unstable

@Light2Dark, want to make an issue on the Narwhals repo, explain our use case, and ask Marco to what extent we can rely on the API, or if he can provide us a semi-private stable API? Hopefully we can find a solution

[Light2Dark]

Looks like narwhals uses left-inclusive, right-inclusive for the first bin (to capture the minimum), and then left-inclusive, right exclusive for the rest. So, 1-2 has six values. But 2-3 doesn't include the last 3 so five values.

Got it, thank you for explaining. That should be okay then, really appreciate the explanation.

marking as draft because I realize the narwhals hist API is marked unstable

@Light2Dark, want to make an issue on the Narwhals repo, explain our use case, and ask Marco to what extent we can rely on the API, or if he can provide us a semi-private stable API? Hopefully we can find a solution

I could do that, we can also fallback to our legacy spec and handling. I removed it because it was cleaner. I think fine to fallback.

edit, actually we lose some perf by fallback. let me check with narwhals. narwhals-dev/narwhals#3249

[mscolnick]

does this need to be optional? or would the json type be empty?

[Light2Dark]

yeah, don't need to, JSONType has None:

    JSONType: TypeAlias = Union[
        Mapping[str, "JSONType"],
        Sequence["JSONType"],
        str,
        int,
        float,
        bool,
        object,
        MIME,  # MIME is a JSONType since we have a custom JSONEncoder for it
        None,
    ]

[mscolnick]

nice work!

[Light2Dark]

merging this in, can test during bug bash