Gridlines absent when no features are present #514

Closed
laceysanderson opened this Issue Sep 19, 2014 · 5 comments

Comments

Projects
None yet
2 participants
@laceysanderson

I have a JBrowse where the reference was loaded with the --noseq option for a FASTA file. When you navigate to a reference sequence for which there are no features in any track, none of the gridlines appear. See: http://knowpulse2.usask.ca/jbrowse/Lentil/index.html?loc=Lc0.7_contig168083638%3A11..90&tracks=Redberry454Contigs&highlight=

This made we worry my JBrowse was broken until I found a scaffold which did have features and was especially worrisome/problematic when I only had the reference loaded and no other tracks. Here's an example from the same JBrowse but where there are features: http://knowpulse2.usask.ca/jbrowse/Lentil/index.html?loc=Lc0.7_scaffold62358-1%3A16421..20822&tracks=Redberry454Contigs&highlight=

Also the JBrowse seems to take an really long time to load which I haven't noticed in other instances. I'm uncertain as to whether this is due to the --noseq option or the number of reference sequences.

~Lacey

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Sep 20, 2014

Contributor

Your refSeqs.json file appears to be about 70+ megabytes even with the --noseq option, so i think this is loaded initially and is making things delayed. It also doesn't look like your server is configured to gzip things on the fly. Maybe the --compress option for prepare-refseqs could help. there's also this pull request for using "fasta indexes" that I haven't been able to test out yet, but I'm wondering if it could help in this situation https://github.com/GMOD/jbrowse/pull/495/files

Also, I was able to load the track eventually but I didn't see the problem with the gridlines! I tested out with firefox 32

Contributor

cmdcolin commented Sep 20, 2014

Your refSeqs.json file appears to be about 70+ megabytes even with the --noseq option, so i think this is loaded initially and is making things delayed. It also doesn't look like your server is configured to gzip things on the fly. Maybe the --compress option for prepare-refseqs could help. there's also this pull request for using "fasta indexes" that I haven't been able to test out yet, but I'm wondering if it could help in this situation https://github.com/GMOD/jbrowse/pull/495/files

Also, I was able to load the track eventually but I didn't see the problem with the gridlines! I tested out with firefox 32

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Sep 23, 2014

Contributor

I tested this out in chrome and you are correct that there are no gridlines on your instance.

Firefox: works
Chrome: doesn't work!

Contributor

cmdcolin commented Sep 23, 2014

I tested this out in chrome and you are correct that there are no gridlines on your instance.

Firefox: works
Chrome: doesn't work!

@laceysanderson

This comment has been minimized.

Show comment
Hide comment
@laceysanderson

laceysanderson Sep 23, 2014

I can confirm I use chrome. Sorry for not including that to begin with…

I'm going to truncate my reference genome to see if that helps either issue but likely won't get to it until tomorrow sometime. This performance hit on large number of reference sequences is quite unfortunate for those of us just in the process of assembling our genome. :(

~Lacey


Lacey-Anne Sanderson
Bioinformaticist
Pulse Crop Breeding and Genetics
Phone: (306) 966-3208
Email: laceyanne_sanderson@shaw.ca
Room 2C33 Agriculture
Department of Plant Sciences
University of Saskatchewan

On Sep 22, 2014, at 6:52 PM, Colin notifications@github.com wrote:

I tested this out in chrome and you are correct that there are no gridlines on your instance.

Firefox: works
Chrome: doesn't work!


Reply to this email directly or view it on GitHub.

I can confirm I use chrome. Sorry for not including that to begin with…

I'm going to truncate my reference genome to see if that helps either issue but likely won't get to it until tomorrow sometime. This performance hit on large number of reference sequences is quite unfortunate for those of us just in the process of assembling our genome. :(

~Lacey


Lacey-Anne Sanderson
Bioinformaticist
Pulse Crop Breeding and Genetics
Phone: (306) 966-3208
Email: laceyanne_sanderson@shaw.ca
Room 2C33 Agriculture
Department of Plant Sciences
University of Saskatchewan

On Sep 22, 2014, at 6:52 PM, Colin notifications@github.com wrote:

I tested this out in chrome and you are correct that there are no gridlines on your instance.

Firefox: works
Chrome: doesn't work!


Reply to this email directly or view it on GitHub.

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Sep 23, 2014

Contributor

If you can enable gzip on your server it should go much faster 👍 alternatively, running prepare-refseqs.pl with --compress would gzip it by default and also be faster. You have to be careful with enabling gzip on the server AND using the compress option because then you get double gzip though :)

This link dscusses how to avoid that.
http://gmod.org/wiki/JBrowse_Configuration_Guide#Compressing_data_on_the_server

Contributor

cmdcolin commented Sep 23, 2014

If you can enable gzip on your server it should go much faster 👍 alternatively, running prepare-refseqs.pl with --compress would gzip it by default and also be faster. You have to be careful with enabling gzip on the server AND using the compress option because then you get double gzip though :)

This link dscusses how to avoid that.
http://gmod.org/wiki/JBrowse_Configuration_Guide#Compressing_data_on_the_server

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Feb 12, 2015

Contributor

I think the fact that no features are present is a red herring, it seems more to have to do with specific zoom levels causing problems.

I think maybe instead of returning "0" gridlines in these cases with odd numbers, (basically the zoom level that i see in the console is 13 pixels per base pair), then i return 5 minor grid lines along with 1 major gridline

diff --git a/src/JBrowse/View/Track/GridLines.js b/src/JBrowse/View/Track/GridLines.js
index bc50fd3..95b1a7b 100644
--- a/src/JBrowse/View/Track/GridLines.js
+++ b/src/JBrowse/View/Track/GridLines.js
@@ -44,8 +44,10 @@ return dojo.declare( BlockBased,
             !( base_span % 10 ) ? 10 :
             !( base_span % 5  ) ? 5  :
             !( base_span % 2  ) ? 2  : 
-                                  0;
+                                  5;

         var major_count = base_span == 20 ? 2 : base_span > 0 ? 1 : 0;

         var new_gridline = function( glclass, position ) {
Contributor

cmdcolin commented Feb 12, 2015

I think the fact that no features are present is a red herring, it seems more to have to do with specific zoom levels causing problems.

I think maybe instead of returning "0" gridlines in these cases with odd numbers, (basically the zoom level that i see in the console is 13 pixels per base pair), then i return 5 minor grid lines along with 1 major gridline

diff --git a/src/JBrowse/View/Track/GridLines.js b/src/JBrowse/View/Track/GridLines.js
index bc50fd3..95b1a7b 100644
--- a/src/JBrowse/View/Track/GridLines.js
+++ b/src/JBrowse/View/Track/GridLines.js
@@ -44,8 +44,10 @@ return dojo.declare( BlockBased,
             !( base_span % 10 ) ? 10 :
             !( base_span % 5  ) ? 5  :
             !( base_span % 2  ) ? 2  : 
-                                  0;
+                                  5;

         var major_count = base_span == 20 ? 2 : base_span > 0 ? 1 : 0;

         var new_gridline = function( glclass, position ) {
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment