Re: [Gmod-ajax] GFF3 slow loading with JBrowse2

[Ke J. <bio...@gm...>]

I never thought this could be region specific. Maybe I'll do more tests
with more regions, so far I've only used a limited number of regions. Could
this also be some problems on the client/browser side, such as too much
memory used by Firefox/Chrome?

Thanks for all the extra info about rendering GFF3. They are really helpful
for me to consider ways to optimize GFF3s for JBrowse2. Really appreciate
it

Ke

On Mon, Nov 22, 2021 at 3:06 PM Colin <col...@gm...> wrote:

> Do you have an example of a region that is slow to load?
>
> The mRNA features would need child feature resolution
>
> The scaffold features would not, and could be added to the dontRedispatch
> list (we could add it to the default list too)
>
> -Colin
>
> On Mon, Nov 22, 2021 at 3:36 PM Ke Jiang <bio...@gm...> wrote:
>
>> Thanks for the info! I took one GFF3, directly coming from Ensembl, and
>> did some digging: the only feature covering the entire chromosomes are
>> "chromosome" features, which should not affect the child feature
>> resolution. But there are about 100 "mRNA" and "scaffold" features that are
>> larger than 1Mbp. They would need full resolution of child features. Would
>> these affect the loading speed?
>>
>> Here is the GFF3 file used, if some tests need to be run:
>>
>> http://ftp.ensembl.org/pub/release-99/gff3/sus_scrofa/
>>
>> The last one in the list called "Sus_scrofa.Sscrofa11.1.99.gff3.gz"
>>
>>
>> On Mon, Nov 22, 2021 at 2:18 PM Colin <col...@gm...> wrote:
>>
>>> One common reason for slowness is if you have features that cover the
>>> entire chromosome for gff3
>>>
>>> The mechanisms of the gff3tabix make it try to resolve all the child
>>> features of large parent features, but if it's e.g. a "region" feature (col
>>> 3 says region) that covers the entirety of chr1, then jbrowse doesn't need
>>> to resolve the child features for that object. By default, region,
>>> chromosome, and contig type gff3 features don't perform this, but if you
>>> have a different type of gff3 feature that covers the entirety of of your
>>> chromosomes, then maybe you can either rename that type to "region" or add
>>> to the "dontRedispatch" config slot on the Gff3TabixAdapter
>>>
>>> -Colin
>>>
>>> On Mon, Nov 22, 2021 at 2:33 PM Ke Jiang <bio...@gm...> wrote:
>>>
>>>> Hi,
>>>>
>>>> I've been playing with JBrowse2 for a while. Recently I noticed that
>>>> GFF3 files, while following the instructions of gt sorting, bgzipping, and
>>>> tabix indexing, still load very slowly on JBrowse2 even for a very small
>>>> genomic interval. An interval as small as 100bp could take up to 5min to
>>>> load. This seems to only happen to those genome-wide GFF3 files such as
>>>> genome annotations and GFFs from StringTie or TopHat pipelines. A BED file
>>>> with a few entries loads very fast when zipped and indexed. BAMs/BigWigs
>>>> also load pretty fast. Does anyone also have this problem or notice similar
>>>> behaviors of large GFF3 files? All files are not stored locally on the
>>>> JBrowse2 server but stay in an S3 bucket on another server, if this
>>>> information helps.
>>>>
>>>> Thanks!
>>>>
>>>> Ke
>>>> _______________________________________________
>>>> Gmod-ajax mailing list
>>>> Gmo...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gmod-ajax
>>>>
>>>