Skip to content

jgd as an alternative graphics device #1679

Closed
#1706
Closed
jgd as an alternative graphics device#1679
#1706
Labels
feature-request

Description

@grantmcdermott
grantmcdermott
opened on Feb 10, 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-R users, 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 main vscode-R extension.

Here's a screen grab:

Image

I'm sharing this background with the vscode-R repo for a couple of reasons:

  • I would welcome additional testers (esp. on Windows)
  • It provides a lightweight alternative to existing R plotting options in VS Code and plays nicely with vscode-R
  • Longer-term, if the community agrees and it survives wider testing, I would be happy to incorporate jgd's functionality into the main R extension code base. At a minimum, it would be nice to add a r.plot.useJgd setting (similar to httpgd). 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

Activity

  1. grantmcdermott
    added
    feature-request
    on Feb 10, 2026

  2. grantmcdermott commented on May 4, 2026

    @grantmcdermott
    grantmcdermott
    on May 4, 2026
    ContributorAuthor

    Update: jgd is 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 jgd VSC extension separately and "manually" enable it as the session backend. One option, which we suggest in the README, is adding the following to your ~/.Rprofile so 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:

    1. Add a r.plot.useJgd setting, so that user's can enable jgd by default, once they have installed the reqs.
    2. Add jgd (both the R package and VSC extension) as dependencies of the main R VSC extension and languageserver packages. 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.

    cc @renkun-ken @randy3k

  3. benz0li commented on May 5, 2026

    @benz0li
    benz0li
    on May 5, 2026
    Contributor

    @grantmcdermott and @eitsupi Thank you for jgd. Great work!

  4. eitsupi commented on May 5, 2026

    @eitsupi
    eitsupi
    on May 5, 2026
    Member
    1. Add a r.plot.useJgd setting, so that user's can enable jgd by 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.

  5. benz0li commented on May 5, 2026

    @benz0li
    benz0li
    on May 5, 2026
    Contributor
    1. Add a r.plot.useJgd setting, so that user's can enable jgd by 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:

    1. b-data's/my JupyterLab R docker stack allows mounting the user's home directory for data persistence.

    2. 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.

    3. The R extension is installed at system level (@builtin, at /opt/code-server/lib/vscode/extensions).

    4. 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:

    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/radian with 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.

  6. renkun-ken commented on May 10, 2026

    @renkun-ken
    renkun-ken
    on May 10, 2026
    Member

    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:

    Looks like more integration needs to be done on the vscode-R side to make it just work out of the box.

  7. benz0li commented on May 10, 2026

    @benz0li
    benz0li
    on May 10, 2026
    Contributor

    b-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

    1. I can add "r.plot.useHttpgd: true" to ~/.local/share/code-server/User/settings.json
    2. newer versions of the R extension do not touch or delete the "r.plot.useHttpgd" setting3 and
    3. a new, separate set of r.plot settings is created for jgd (or more generally: The r.plot.backend)

    everything should be fine.

    Footnotes

    1. Similar to https://github.com/Harvard-ATG/ood-jupyterlab-apptainer ↩

    2. Not being rebuilt; fixed CRAN/CTAN date; meant for reproducible research ↩

    3. Not being displayed in the UI is 🆗. It just needs to persist in the settings.json. ↩

  8. grantmcdermott commented on May 10, 2026

    @grantmcdermott
    grantmcdermott
    on May 10, 2026
    ContributorAuthor

    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.

  9. renkun-ken commented on May 11, 2026

    @renkun-ken
    renkun-ken
    on May 11, 2026
    Member

    @grantmcdermott I'm using jgd in my daily work now. I'll file issues if I find anything that might be improved.

  10. grantmcdermott commented on May 12, 2026

    @grantmcdermott
    grantmcdermott
    on May 12, 2026
    ContributorAuthor

    PR here if anyone would like to review: #1706

  11. randy3k
    closed this as completedin #1706on Jun 29, 2026
  12. randy3k
    added a commit that references this issue on Jun 29, 2026

    feat(plot): add JGD graphics device integration

    3041ca6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature-request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions