feat(plot): addjgd graphics device integration

[grantmcdermott]

Closes #1679

Embeds the jgd VS Code extension code directly into vscode-R. Users only need the jgd R package installed on their system---and there's a graceful fallback otherwise---with no separate extension required.

Details

Adds a new r.plot.backend enum setting (auto | standard | httpgd | jgd). Default is auto, which tries the best available backend at runtime:

1. If r.plot.useHttpgd is true → httpgd (ensures backwards compatability)
2. Otherwise R-side hooks follow this logic: jgd (if installed) → httpgd (if installed) → standard

This means users who install.packages("jgd") get interactive plots with zero configuration. (Note: I didn't want to presume that the jgd R package becomes a hard dependency, but am happy to adjust if others feel differently.)

Whenjgd is active:

• Extension starts a Unix socket / named pipe server on activation
• JGD_SOCKET and SESS_PLOT_BACKEND env vars are passed to R terminals
• R's sess::register_hooks() sets jgd::jgd() as the default device
• Plots stream as JSONL frames over the socket and render via Canvas2D in a dedicated webview panel
• Plot history, navigation (prev/next/first/last), delete, resize, and PNG/SVG export all work

Main files

I've added three new files to src/plotViewer/ (ported from from the currently standalone jgd VSC extension):

• jgdPlotHistory.ts — multi-session plot history with eviction and resize-after-delete protection
• jgdSocketServer.ts — socket server managing concurrent R sessions and JSONL routing
• jgdViewer.ts — JgdManager + JgdViewer (Canvas2D webview with font metrics pipeline)

UX

JGD-specific settings:

• r.plot.jgd.historyLimit
• r.plot.jgd.exportWidth
• r.plot.jgd.exportHeight
• r.plot.jgd.exportDpi.

R-side changes: sess::connect() and sess::register_hooks() gain a use_jgd parameter. The hook priority is jgd > httpgd > standard, gated on package availability and JGD_SOCKET being set.

Backward compatibility: r.plot.useHttpgd is deprecated but still respected. When r.plot.backend is auto (default) and r.plot.useHttpgd is true, httpgd is forced. Existing Docker images and devcontainer configs will continue to work without changes.

Screenshots

[randy3k]

I haven't had a chance to use jgd, will let @renkun-ken review it. Anyway, great work!

[benz0li]

Adds a new r.plot.backend enum setting (auto | standard | httpgd | jgd). Default is auto, which tries the best available backend at runtime:

👍

1. If r.plot.useHttpgd is true → httpgd (ensures backwards compatability)
2. Otherwise R-side hooks try jgd (if installed) → httpgd (if installed) → standard

The r.plot.backend enum setting (alone) is sufficient.
👉 I simply set "r.plot.backend": "httpgd" if I want to continue using httpgd.

IMHO the handling of setting r.plot.useHttpgd can be removed.

[benz0li]

No handling = no tinkering (touching, deleting, etc.) of setting "r.plot.useHttpgd: true" in ~/.local/share/code-server/User/settings.json

If r.plot.useHttpgd is true → httpgd (ensures backwards compatability)

This actually breaks forward compatibility.

---

What I intend to do: My default ~/.local/share/code-server/User/settings.json for the R extension will be

{
  "r.bracketedPaste": true,
  "r.plot.useHttpgd": true,
  "r.plot.backend": "auto",
  "r.rterm.linux": "/usr/local/bin/radian",
  "r.rterm.option": [
    "--no-save",
    "--no-restore"
  ],
  "r.workspaceViewer.showObjectSize": true,
}

This will lead to the following behaviour:

• Newer versions of the R extension will interpret r.plot.backend (only) and use jgd (if installed).
  • If jgd is not installed: Fallback to httpgd (if installed); otherwise fallback to standard.
• Older versions (≤ 2.8.8) of the R extension will interpret "r.plot.useHttpgd": true (only) and use httpgd.

[benz0li]

@grantmcdermott I am just realising that my detailed comments at #1679 have caused more confusion than clarity.

Sorry about that.

[eitsupi]

I haven't looked at the details, but based on the description, I think it would be better to do it this way.

• Delete old setting r.plot.useHttpgd
• In auto mode, the priority is set to httpgd, then jgd.
  This means that in older environments where httpgd is installed, httpgd will continue to be used automatically.

I'm also wondering if we could remove the svglite backend for simplification.
At the very least, I don't think it should be a hard dependency of the sess package.
I believe jgd is lighter than svglite.

[grantmcdermott]

Thanks for the quick comments. I don't want to respond to everything until @renkun-ken has had a chance to review. But just quickly:

• RE: removing the r.plot.useHttpgd setting. I think we should follow the follow the mode (exemplified by data.table, etc. ) of soft deprecating functions for at least one release cycle, before fully removing them. Also, I think that this solution is more elegant i.t.o. of fallback than switching straight (only) to the auto enum setting. Remember: we're active and up to date users of vscode-R. I think most normies would be caught out if their settings suddenly stopped working altogether.
• RE: auto default. I personally think jgd makes the most sense as the lighter (and now native) alternative, but will defer to the maintainers.
• Similarly, yes, jgd is definitely a lighter dep than svglite (incl. no recursive sysdeps), but I'm not sure if they're a like-for-like swap in this context.

[benz0li]

I think most normies would be caught out if their settings suddenly stopped working altogether.

If it is implemented as @eitsupi suggests, IMHO everything will continue to work as usual.

[eitsupi]

My understanding is that only httpgd offers features like thumbnail display for past plots, so it makes sense to prioritize httpgd over jgd in environments where httpgd is installed.

Another point that caught my attention is that the tests don't seem to have been ported from the jgd repository.

[renkun-ken]

Looks user-created R session does not respect r.plot.backend setting as is not reflected in the attach script.

[grantmcdermott]

Looks user-created R session does not respect r.plot.backend setting as is not reflected in the attach script.

Thanks. Should be fixed now.

Another point that caught my attention is that the tests don't seem to have been ported from the jgd repository.

I think these only touch the Deno server, right? Porting them to VS Code is out-of-scope IMO.

[eitsupi]

I think these only touch the Deno server, right? Porting them to VS Code is out-of-scope IMO.

I meant these files.
https://github.com/grantmcdermott/jgd/blob/b556d1cc0bc94a83628045e12ea5e71ec8342480/vscode-ext/src/plot-history.test.ts
https://github.com/grantmcdermott/jgd/blob/b556d1cc0bc94a83628045e12ea5e71ec8342480/vscode-ext/src/socket-server.test.ts

[grantmcdermott]

I think these only touch the Deno server, right? Porting them to VS Code is out-of-scope IMO.

I meant these files. https://github.com/grantmcdermott/jgd/blob/b556d1cc0bc94a83628045e12ea5e71ec8342480/vscode-ext/src/plot-history.test.ts https://github.com/grantmcdermott/jgd/blob/b556d1cc0bc94a83628045e12ea5e71ec8342480/vscode-ext/src/socket-server.test.ts

A good catch. I'll port those (second one might be a bit trickier given we changed some things from the original extension, but it should work...)

[renkun-ken]

if r.plot.backend = "auto":

From the perspective of current capabilities:

httpgd > jgd > svglite > png

From the perspective of hard dependencies, footprints, things to be loaded into the user session:

png > jgd > svglite > httpgd

From a balanced view of both perspectives as well as native extension support, jgd is a good choice I guess?
It largely depends how we weight each perspective.

From user-side, if loading a ton of hard dependencies is not a big deal, choosing the currently most capable installed backend might make more sense.

From the status quo, I guess a good proportion of existing users use httpgd as a suggested approach to view graphics, with their r.plot.useHttpgd being enabled, which will force using httpgd even if r.plot.backend = "auto" by default as we release. Even if we choose the behavior to make jgd > httpgd for "auto", if httpgd users wants to check out jgd, they have to disable r.plot.useHttpgd first and install jgd; if new users wants to check out jgd, just install it and it should work.

Considering all these, I think it is fair to make jgd > httpgd as we don't want to introduce a heavier dependency for user workflow by default.

The only thing that might be a bit drawback is that do we think jgd has reached a level of stability that could be released/set by default if installed?

[eitsupi]

In my opinion, if httpgd is removed from CRAN again (which is likely to happen in the not-too-distant future), leaving the useHttpgd setting in place will leave lasting problems.