Upgrade to JBrowse V2 - Githubissues

victorlin commented 3 years ago

Preview link: https://dev-jbrowse.serratus.io/

closes #127
closes #102
closes #103

Note:

chunkSizeLimit used to be 4,0000,000; it is now 100,000,000 [src]

victorlin commented 3 years ago

Hey @cmdcolin, thanks for the pointer! The LGV works great after a bit of tinkering. One question: is there a way to "lazy load" large alignments like before? Example:

Old: delays load until zooming into a smaller region

https://serratus.io/jbrowse?bam=SRR9966509&loc=MG197718.1

New: attempts to load all at once, which takes ~1m

https://dev-jbrowse.serratus.io/jbrowse?bam=SRR9966509&loc=MG197718.1

cmdcolin commented 3 years ago

There are a couple factors that may be at play

1) We do not do stats estimation as jbrowse 1 does currently. this would indeed be good to do. See https://github.com/GMOD/jbrowse-components/issues/607 for example 2) We have a particular bug that affects the embedded usage of the code, see https://github.com/GMOD/jbrowse-components/issues/2038 and this results in slowness on alignments tracks. that is a high priority to fix

We have a setting that can help with number (1) where it disables drawing until a user is zoomed in with a config setting named maxDisplayedBpPerPx

This is a bit tedious to configure but here is a full example of this (needs to set the "maxDisplayedBpPerPx" setting on both the "pileup" and "snpcoverage" displays)

{
      "type": "AlignmentsTrack",
      "trackId": "mytrack",
      "name": "mytrack",
      "assemblyNames": ["myasm"],
      "adapter": {
        "type": "BamAdapter",
        "bamLocation": {
          "uri": "file.bam"
        },
        "index": {
          "location": {
            "uri": "file.bam.bai"
          }
        }
      },
      "displays": [
        {
          "type": "LinearAlignmentsDisplay",
          "displayId": "mydisp_alignments",
          "pileupDisplay": {
            "type": "LinearPileupDisplay",
            "maxDisplayedBpPerPx": 4,
            "displayId": "mydisp_pileup"
          },
          "snpCoverageDisplay": {
            "type": "LinearSNPCoverageDisplay",
            "maxDisplayedBpPerPx": 4,
            "displayId": "mydisp_snpcov"
          }
        }
      ]
    },

That makes it so you have to zoom in closer than about 5,000bp in the visible range (the measurement is bpPerPx so the track is displayed only when there are less than 4 basepairs per pixel)

cmdcolin commented 3 years ago

(you can possibly use v1.1.0 of the package to avoid the issue mentioned in (2), the slowness was accidentally introduced in v1.2.0)

victorlin commented 3 years ago

@cmdcolin thanks for the tips! Will try them out and let you know how it goes.

victorlin commented 3 years ago

@cmdcolin updates per suggestion:

This works and should be a good short-term solution. However, attempts to load LinearPileupDisplay or LinearSNPCoverageDisplay result in this browser console error (example):

Uncaught Error: [mobx-state-tree] Cannot resolve a reference to type '(LinearPileupDisplayConfigurationSchema | LinearSNPCoverageDisplayConfigurationSchema | LinearAlignmentsDisplayConfigurationSchema | LinearBareDisplayConfigurationSchema | LinearBasicDisplayConfigurationSchema | LinearReferenceSequenceDisplayConfigurationSchema | ChordVariantDisplayConfigurationSchema | LinearVariantDisplayConfigurationSchema | LinearWiggleDisplayConfigurationSchema)' with id: 'SRR9966509-LinearPileupDisplay' unambigously, there are multiple candidates: /config/tracks/0/displays/0/pileupDisplay, /config/tracks/0/displays/1

Not a huge deal since LinearAlignmentsDisplay is already a combination of both.

Downgrading to 1.1.0 results in this runtime error which fails to render the component:

Error: A React component suspended while rendering, but no fallback UI was specified.

Add a <Suspense fallback=...> component higher in the tree to provide a loading indicator or placeholder to display.
    in Unknown (created by JBrowseLinearGenomeView)
    in div (created by ForwardRef(Paper))
    in ForwardRef(Paper) (created by WithStyles(ForwardRef(Paper)))
    in WithStyles(ForwardRef(Paper)) (created by ViewContainer)
    in div (created by ForwardRef(Paper))
    in ForwardRef(Paper) (created by WithStyles(ForwardRef(Paper)))
    in WithStyles(ForwardRef(Paper)) (created by ViewContainer)
    in ViewContainer (created by JBrowseLinearGenomeView)
    in div (created by JBrowseLinearGenomeView)
    in JBrowseLinearGenomeView (at Jbrowse.jsx:103)
    ...

cmdcolin commented 3 years ago

there is a new version 1.3.2 that has a couple fixes, not sure if it specifically addresses all the concerns but welcome to try it out

victorlin commented 3 years ago

@cmdcolin thanks! It feels much snappier compared to 1.3.0. We'll be going forwards with this one.

cmdcolin commented 3 years ago

this is quite cool! one random thing is that, sometimes, it's hard to see where to navigate to see the reads. e.g. if i click frank the bat, the default contig that is selected is NC_045512.2 but there are no reads that are mapped to that contig. have to manually inspect the BAM and find that the reads are mapped to e.g. EU769558.1

not sure if there is an easy fix, or whether jbrowse can help there

victorlin commented 3 years ago

@cmdcolin I guess the JBrowse link at the top of the page isn't very useful. Typically, you'll want to use one of the sequence-level matches which will directly link to reads associated with a specific sequence (or JBrowse location). Show all regions in assembly is also uninformative since we have too many sequence names associated with each BAM.

@ababaian should we remove the top JBrowse link?

Direct links for comparison:

serratus-bio / serratus.io

Upgrade to JBrowse V2 #141