Investigate possible performance issues in VSCode

[nx10]

I'm using httpgd inside of VS-Code together with the R extension. I can easily kill httpgd with

plot(rnorm(1000000), rnorm(1000000))

Which, admittedly, are a lot of points. I have some more complicated ggplots with fewer points that also fail. However, creating a reprex here wouldn't be that easy. However, if you think a reprex of those plots would be beneficial, I'll create one for you.

I usually save my plots using ggsave or using tikzdevice. So this does not rely on httpgd right? Saving is never a problem.

Originally posted by @BerriJ in #92 (comment)

[combiz]

Firstly, great work so far on this package!

I'd like to second this suggestion. I work in single-cell genomics where we often generate scatterplots with 500,000+ individual points. These don't display inside the httpgd window of vs-code (it remains greyed out), but it's occasionally possible to view one plot (max, and after extensive loading) in the 'External Browser' view.

I wonder if there are vs-code memory limit parameters that impact this, as the quantity of data involved is modest relative to the RAM available (256 GB). Thanks.

[savyajha]

I'm not sure whether this is a vscode issue or not, because I'm hitting it even when opening the httpgd link in a web browser (using Fedora on WSL with R 4.1.3, no usage of vscode). I've got around (I think) 120,000 points and the graph literally takes 30 seconds to load in the viewer. The lag in navigating the interface is fairly large and working with multiple plots is difficult.

Please let me know if I can help in any way in narrowing this problem down or helping out in working it out.

Edit: All it took was installing svglite to get my problems to go away. My bad.

[nx10]

I'm not sure whether this is a vscode issue or not, because I'm hitting it even when opening the httpgd link in a web browser (using Fedora on WSL with R 4.1.3, no usage of vscode). I've got around (I think) 120,000 points and the graph literally takes 30 seconds to load in the viewer. The lag in navigating the interface is fairly large and working with multiple plots is difficult.

Edit: All it took was installing svglite to get my problems to go away. My bad.

Thank you for checking out httpgd!

This does not have anything to do with svglite httpgd ships with it's own SVG renderer which was originally based on svglite, but is faster. (httpgd renderers use a different architecture than "traditional" R renderers.)
I think what you were observing may have been caused by two or more windows viewing plots at the same time (this may cause httpgd to have a lot of uneccesarry re-renders).

Are you using the CRAN version of httpgd or the newest Github version?

Some technical explanation to the performance problems:

SVG plots with a high number of points need a styled <circle ... /> tag for each one of them which massively increases the file and buffer size needed. I am not aware of anything in the SVG spec that could help with that.
For this reason I think the best course of action would be to switch to PNG rendering for clients. (Or: give the option to either render all plots, or plots with a high number of draw-calls, to PNG)
The problem with that is that the PNG renderer (which is based on the one in r-base) uses the cairo library, which does CPU graphics and is comparatively slow.
For all of these reasons I am actively working on writing a GPU based renderer directly in OpenGL (and might do Vulkan/Metal after if I don't burn out).

I will most likely post news about the GPU renderer over at unigd soon.

[savyajha]

I think what you were observing may have been caused by two or more windows viewing plots at the same time (this may cause httpgd to have a lot of uneccesarry re-renders).

This is probably what it was: I've tried to recreate the issue on various different renvs and am failing to do so. I have no idea what caused it then and what caused it to resolve. My apologies for the false alarm.