JBrowse2 vs @jbrowse/img

[kcleal]

Hi @cmdcolin,

Ive been benchmarking static image generation functionality using the "@jbrowse/img" plugin, but was wondering how the performance of the plugin differs from the full JBrowse2 application? I was under the assumption that the img plugin and main application are essentially the same tool, and the performance of the plugin is representative of jbrowse2. I have been referring to using the "@jbrowse/img" plugin as using "JBrowse2", but I suppose this is not accurate. Would you be able to give any insight in to how the two differ, and guidance of how to describe the relationship between the two? Thanks!

[cmdcolin]

Hi there sorry for the delayed response. Was vacationing:)

It is hard to say exactly, if you wanted to refer to it as @jbrowse/img it would be most specific. you can see how it can be tricky to refer to things when we have a 'number of different jbrowse 2 products' with varying technical aspects

here are some descriptions if it helps

• jbrowse-web - our pre-bundled app (bundle referring to e.g. webpack outputting js and html and css files) product with multiple 'view types' that we produce a zip file for that people can download, probably the most common use of jbrowse 2 for deployment on websites. it uses webworkers to try to parallelize some tasks. it also renders some offscreen data for side scrolling on load.
• jbrowse-desktop - electron packaging of jbrowse 2, very similar to jbrowse-web in look and feel. it uses webworkers to try to parallelize some tasks
• @jbrowse/react-linear-genome-view - a NPM package that shows a single "jbrowse 2 linear genome view" as a react component. it optionally allows developers to use webworkers. users run their own bundler generally for this product, and bundlers are finicky with worker code so that is why it is optional
• @jbrowse/img - a command line tool that renders SVG for a single "jbrowse 2 linear genome view". it uses the same code that clicking "export svg" in the browser would run. it does not use any "headless browser": it is just a nodejs program that does "react server side rendering". it does not use web workers or nodejs workers, though that could maybe be added. it also 'only renders the data in the visible region'.

generally the parallelism from webworkers is only used for multiple tracks in our codebase. each track is assigned a worker id in a worker pool. for a single bam track, there is no parallelism benefit. our paper details some of the ways i performance profiled the app. I instrumented the tests for our paper to use jbrowse-web which is what i thought was the most representative experience for a user would be. It is somewhat tedious to instrument but uses puppeteer and it just detects that some number of 'completed' DOM nodes are visible, corresponding to different 'blocks' that are all rendered independently (theres no "completed rendering" event emitted by jbrowse 2. might be good to add this though) https://github.com/GMOD/jb2profile/blob/master/profile_jb2web.js

[kcleal]

@cmdcolin thanks for the detailed answer. I will use the @jbrowse/img name from now on