New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Selecting large gene with many transcripts delays browser::should open subfeatures on demand isntead #559

Closed
kshefchek opened this Issue Jan 27, 2015 · 11 comments

Comments

Projects
None yet
5 participants
@kshefchek

kshefchek commented Jan 27, 2015

I'm having an issue with Jbrowse when using firefox 35.0.1. When going here:
http://icebox.lbl.gov/WebApolloHuman/jbrowse/?loc=BRCA1
and select the gene, I get this message:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.
Script: http://icebox.lbl.gov/WebApolloHuman/jbrowse/src/dojo/dojo.js:194

@cmdcolin

This comment has been minimized.

Contributor

cmdcolin commented Jan 27, 2015

I mentioned this to @nathandunn but I think it's just loading a lot of data here

It looks like it is just trying to load too much data at once into the dialog box, but it does open eventually at least on my machine

You could try to set maxFeatureSizeForUnderlyingRefSeq in the jbrowse config files to prevent it loading so much data

That will tell jbrowse not to load sequence data for dialog boxes when features over a certain size (default 250kb)

We'll follow up

@nathandunn

This comment has been minimized.

Contributor

nathandunn commented Jan 27, 2015

@cmdcolin I set the max to 2.5M. It does eventually come back (in both firefox and chrome). I get the same result for either track. Would be nice if it would load on-demand instead of pausing to load all of the data.

@cmdcolin

This comment has been minimized.

Contributor

cmdcolin commented Jan 27, 2015

The default is 250kb so that is raising it, however, even when it is set to 0, the dialog box can still take a long time.

I would probably need more time to look at a profiling tool to see what is causing that, but setting maxFeatureSizeForUnderlyingRefSeq to 0 should at least save a couple seconds

@nathandunn nathandunn changed the title from Selecting gene kills browser when using firefox to Selecting large gene with many transcripts delays browser::should open subfeatures on demand isntead Jan 28, 2015

@nathandunn

This comment has been minimized.

Contributor

nathandunn commented Jan 28, 2015

@cmdcolin This does help some. I guess what I'd like to see instead is for it to open features / subfeatures on-demand (preferable) or in a logical order. Seeing every CDS when its hard to tell from the interface which one is which makes things difficult. However if I clicked on a particular transcript / CDS I could have it highlight or focus . . that would be great.

Not an easy solution, but I think it makes sense to do at some point.

@selewis

This comment has been minimized.

selewis commented Feb 2, 2015

I believe the solution we came to was to go ahead and load all the
transcripts, but delay loading of the metadata which is what the big
time-sink is. That is, first pass just load what is minimally needed for
the graphics (the intervals) and defer anything else.

-S

On Wed, Jan 28, 2015 at 8:53 AM, Nathan Dunn notifications@github.com
wrote:

@cmdcolin https://github.com/cmdcolin This does help some. I guess what
I'd like to see instead is for it to open features / subfeatures on-demand
(preferable) or in a logical order. Seeing every CDS when its hard to tell
from the interface which one is which makes things difficult. However if I
clicked on a particular transcript / CDS I could have it highlight or focus
. . that would be great.

Not an easy solution, but I think it makes sense to do at some point.


Reply to this email directly or view it on GitHub
#559 (comment).

@rbuels

This comment has been minimized.

Collaborator

rbuels commented Feb 1, 2018

go ahead and load all the
transcripts, but delay loading of the metadata which is what the big
time-sink is

Was this ever implemented? And does anybody have an up-to-date link showing this problem?

@rbuels rbuels added this to the 1.12.4 milestone Feb 1, 2018

@cmdcolin

This comment has been minimized.

Contributor

cmdcolin commented Feb 1, 2018

This was implemented as a config called subfeatureDetailLevel (#861) but its a little unintuitive for most users

@cmdcolin

This comment has been minimized.

Contributor

cmdcolin commented Feb 1, 2018

And by users I mean admins setting up a browser

@rbuels

This comment has been minimized.

Collaborator

rbuels commented Feb 1, 2018

Yeah, I'd like to avoid having the browser hang under any circumstance. If it's too big, it should throw a descriptive error, maybe even crash the whole session, but never hang. Basically, I always think of it in terms of: is there potential for somebody to get completely stuck by this, to the point of them having to email the mailing list? If so, we need to see what we can do to smooth it over.

@rbuels rbuels modified the milestones: 1.12.4, 1.12.5 Feb 2, 2018

@rbuels

This comment has been minimized.

Collaborator

rbuels commented Feb 27, 2018

The original link for this issue seems to be gone now, does anybody have a link that demonstrates the problem?

@cmdcolin

This comment has been minimized.

Contributor

cmdcolin commented Feb 27, 2018

Pretty much any gene that is pretty long and has many transcripts will take a long time to popup the View details popup

Wormbase has some examples perhaps, for example wormbase gene (etr-1) has a ton of subfeatures and can take awhile to enable the popup

http://www.wormbase.org/tools/genome/jbrowse-simple/?data=data%2Fc_elegans_PRJNA13758&loc=II%3A146175..186314&tracks=Curated_Genes&highlight=

Possible solutions

a) heuristic for dynamically putting subfeatureDetailLevel on
b) make a more intelligent popup that doesn't have lots of textboxes (maybe just one textbox with the sequence for the subfeatures highlighted)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment