Repository navigation
jgd as an alternative graphics device #1679
Description
Activity
Update:
jgdis now available on CRAN and has been pretty thoroughly tested (thanks to everyone who provided feedback!) Here's a demo of it in action.jgd-demo.mp4
Provided that this sounds desirable, I'd love to move forward with tighter integration with the main R VS Code extension. Right now, users still need to download our little
jgdVSC extension separately and "manually" enable it as the session backend. One option, which we suggest in the README, is adding the following to your~/.Rprofileso that it automatically activates for VSC R sessions:if (interactive() && Sys.getenv("TERM_PROGRAM") == "vscode" && Sys.getenv("POSITRON") != "1") { jgd::jgd() }
Still, it would be nice to enable this as part of the native R VSC experience. I see two high-level options:
- Add a
r.plot.useJgdsetting, so that user's can enablejgdby default, once they have installed the reqs. - Add
jgd(both the R package and VSC extension) as dependencies of the main R VSC extension andlanguageserverpackages. This is obviously a more aggressive integration and I don't mean to sound presumptuous here... I only mention it since our extension directory is pretty lightweight and I would be happy to transfer it if that sounds of interest.
No pressure or obligation. But do let me know if either of those options sounds reasonable. If there's traction, then I'll work on an appropriate PR.
- Add a
@grantmcdermott and @eitsupi Thank you for jgd. Great work!
Reacted by Grant McDermott- Add a
r.plot.useJgdsetting, so that user's can enablejgdby default, once they have installed the reqs.
In my opinion, it would be better to use an Enum selection instead of adding such a setting.
- Add a
- Add a
r.plot.useJgdsetting, so that user's can enablejgdby default, once they have installed the reqs.
In my opinion, it would be better to use an Enum selection instead of adding such a setting.
Can this setting be added in a way that ensures backward compatibility?
What I mean by backwards compatibility:
-
b-data's/my JupyterLab R docker stack allows mounting the user's home directory for data persistence.
-
The default code-server settings for the R extension are
{ "r.bracketedPaste": true, "r.plot.useHttpgd": true, "r.rterm.linux": "/usr/local/bin/radian", "r.rterm.option": [ "--no-save", "--no-restore" ], "r.workspaceViewer.showObjectSize": true, }and stored (persisted) at
~/.local/share/code-server/User/settings.json. -
The R extension is installed at system level (
@builtin, at/opt/code-server/lib/vscode/extensions). -
A home directory created with a newer version [of b-data's/my images] can also be mounted with an older version.
This leads to the following situation:
- If there is a new setting: Mounting with an older version will automatically add
"r.plot.useHttpgd": true.
ℹ️ https://github.com/b-data/jupyterlab-r-docker-stack/blob/f2546039d831856a8346972776023a7bc8bc395d/base/scripts/usr/local/bin/before-notebook.d/30-code-server.sh#L16-L23- IMHO a new setting will be ignored by the older version of the R extension.
- The setting persists and will be still there when the home directory is mounted with a newer version [of b-data's/my images].
- Will setting
"r.plot.useHttpgd": truecontinue to exist and remain untouched by an upcoming version of the R extension?
- Will setting
P.S.: How I handle it for the now deprecated radian and setting
"r.rterm.linux": "/usr/local/bin/radian": I install arf now and set up/usr/local/bin/radianwith the following content:#!/bin/bash echo "radian is deprecated. Starting arf instead..." echo exec /usr/local/bin/arf "${@}"
👉 Users can leave setting
"r.rterm.linux": "/usr/local/bin/radian"untouched.- Add a
Thanks for the nice work, @grantmcdermott. Recently, some nice works (of course including jgd) have been under active development which I believe would be promising for the vscode-R experiences:
- vscode-R 3.0.0-rc
- https://github.com/eitsupi/arf
- https://github.com/grantmcdermott/jgd
Looks like more integration needs to be done on the vscode-R side to make it just work out of the box.
Reacted by Olivier Benz, chmzs, Randy Lai and mihemb-data's/my JupyterLab R docker stack is also used on HPC Slurm clusters (accessible via Open OnDemand, started using Apptainer1).
ℹ️ In such a setup, the same home directory is used by default for every Slurm job of the user.Current images in use:
[CUDA 13] R 4.6 + Python 3.14- coder-server v4.118.0 (aka Code - OSS v1.118.0)
- R extension v2.8.8
[CUDA 13.2] R 4.5.3 + Python 3.13.11- coder-server v4.117.0 (aka Code - OSS v1.117.0)
- R extension v2.8.8
[CUDA 12.8] R 4.4.3 + Python 3.12.10- coder-server v4.99.2 (aka Code - OSS v1.99.2)
- R extension v2.8.5
[CUDA 11.8] R 4.3.3 + Python 3.11.9- coder-server v4.23.0 (aka Code - OSS v1.88.0)
- R extension v2.8.2
When these images were created, all extensions were installed at system level.
👉 This ensures compatibility with the code-server version available in these images.This also implies that the older versions2 of the image/'R extension' rely on setting
"r.plot.useHttpgd": true.As long as
- I can add
"r.plot.useHttpgd: true"to~/.local/share/code-server/User/settings.json - newer versions of the R extension do not touch or delete the
"r.plot.useHttpgd"setting3 and - a new, separate set of
r.plotsettings is created for jgd (or more generally: Ther.plot.backend)
everything should be fine.
Footnotes
-
Similar to https://github.com/Harvard-ATG/ood-jupyterlab-apptainer ↩
-
Not being rebuilt; fixed CRAN/CTAN date; meant for reproducible research ↩
-
Not being displayed in the UI is 🆗. It just needs to persist in the
settings.json. ↩
Thanks @renkun-ken. I'll take that as implicit approval for tighter integration. I'll think/work on a PR and see what feels most appropriate.
@benz0li Thanks for chiming in. I agree ofc that minimizing breaking changes (or, worse, silent failures) is optimal. But OTOH a major release is the time to do this and, with 3.0.0 around the corner, we can at least strike while the iron is hot.
Reacted by Kun Ren@grantmcdermott I'm using jgd in my daily work now. I'll file issues if I find anything that might be improved.
Reacted by Grant McDermottPR here if anyone would like to review: #1706
- added a commit that references this issue
on Jun 29, 2026
Hi folks.
I've been working on a lightweight R graphics device called jgd (link). The core idea is to serialize R plotting operations into JSON and then display them in an external renderer. The underlying R package is mostly written in pure C, has no external dependencies, and plugs directly into R's C API.
More relevant for
vscode-Rusers, however, is that fact that the primary application right now is an embedded plot view in VS Code. The extension itself is pretty small, but has the core "nice UX" features that I want (cycling through plots, automatic resizing, export features, etc.). It also plays well with the mainvscode-Rextension.Here's a screen grab:
I'm sharing this background with the
vscode-Rrepo for a couple of reasons:vscode-Rr.plot.useJgdsetting (similar tohttpgd). At a maximum, and not to be presumptuous, but perhaps we could fully integrate jgd into the main R extension, since this would enable nice plotting functionality out of the gate.More details are available at the jgd repo: https://github.com/grantmcdermott/jgd