Add canvas feature renderer

[cmdcolin]

This is a draft PR for canvas feature rendering

I am observing that SVG feature rendering is pretty slow in some cases especially if we are moderately zoomed out. the process of creating a react component for every subfeature, with config callbacks, color emphasize routines, is labor intensive, and bloats the dom node count, and it runs basically the full render on both the worker (ssr) and client thread (hydrate also does a full render).

Also this PR has floating feature labels which is a good benefit.

Some todos include just a general code review and adding UTR

Fixes #674

[cmdcolin]

one concern that could be brought up is that some users have created infrastructure around svg being the default renderer. possibly, in that case, we would need to fork stuff in a (very) similar way to jbrowse 1 and make a CanvasFeatures track and an SvgFeatures track, which FeatureTrack being the default with svg renderer.

[cmdcolin]

just for the record, this is definitely way faster === more pleasant to use imo. if there are considerations before pushing forward on this, feel free to add, but could be worth pushing over the finish line

[rbuels]

from meeting just now, thinking about how to allow pluggable Glyphs.

two ways of doing this I can think of:

1. add a pluggable element type called a CanvasFeatureGlyphType, add it to the plugin manager, etc.
2. add an extension point called CanvasFeatures-chooseGlyph that lets people modify the code that chooses what glyph class to use

[john-portwood]

Once this feature is implemented, would we be able to create JBrowse2 tracks from data that was loaded as CanvasFeatures from JBrowse1? We have an existing JBrowse1 installation on it with hundreds of tracks (many of which are CanvasFeatures), and it would be slick if I could re-create all those tracks in JB2 by just pointing to the same data sources that our JB1 instance is using.

Appreciate all of your efforts on this!

[cmdcolin]

Hi @john-portwood !

I would be very enthusiastic to hear about jbrowse 2 adoption efforts with MaizeGDB

It is somewhat technical but this PR is basically a performance optimization that makes very feature-dense feature tracks render faster. It wouldn't have much bearing on converting jbrowse 1 to jbrowse 2 for most cases.

You should be able to point jbrowse 2 at all your existing data sources for jbrowse 1. We don't have a super automated way to convert from a jbrowse 1 to a jbrowse 2 config, but I have a sort of hacky script. I ran it over the b73 config and it generated this...live instance here

https://jbrowse.org/code/jb2/main/?config=/demos/maizegdb/B73/config.json

converter https://gist.github.com/cmdcolin/79e1a9bc55e24e5b0b42903378aa5e0c

You can see a couple things in the converter are hardcoded for b73 but it's largely automated. You might have to do some extra work to port over custom configuration color callbacks and other customizations, but i'd be happy to help :) if you have any other questions let me know

[cmdcolin]

little more maize data exploration: added a Maize SNP VCF files and put it in the multi-sample variant display mode, it took like 30seconds to render and cluster (has a little built in clustering of genotypes), so kind of intensive but produces cool patterns!

yellow = vcf no call (sometimes indicative of a deletion)
light blue = heterozygous alt
dark blue = homozygous alt
grey = ref

can also make it filter out SNPs to focus on larger indels e.g. >10bp

if there was a structural variant VCF, can render those as well...and synteny data...and probably other stuff!

[john-portwood]

Hi Colin,

Your converter script was an absolute godsend and saved me so much time, thank you so much!!! I'm just getting started with the migration efforts, but am excited for this project. We're hosting it here: https://jbrowse2.maizegdb.org/, but won't be advertising it to our users until it's ready. The VCF track you're showing in the screenshot looks incredibly cool -- I don't think we're hosting VCF data in our JB1 instance but I definitely want to explore that more now.

We do use a lot of callbacks for customizations, and so I suspect that will be the biggest lift in the migration, but if I have any questions I'll be sure to let you know. Thank you so much again for your amazing work!