Closed hexylena closed 8 years ago
@erasche Did you test this against the master JBrowse? I removed the gradients in this pull request:
https://github.com/GMOD/jbrowse/pull/721
However, make sure that it is reading your colors properly. I didn't check for that. Hopefully we can coordinate a 1.12.2 JBrowse / 2.0.3 JBrowse release.
@nathandunn Didn't test elsewhere, just saw this pop up before had to give a short talk.
As for which version, I don't completely know.
This was tested on version 076f3a7227f9a9d061724fb23939339122ca9648 of apollo, which used whatever the default behaviour was for including JBrowse.
Right, but whatever you have in apollo-config.groovy will over-ride what is in Config.groovy. You’ll what to do a master pull so that it uses bower to install jbrowse.
The jbrowse version of your apollo-config.groovy can be commented out (or you can just copy it). What you need is this:
git { url= "https://github.com/GMOD/jbrowse" // tag = "1.12.1-release" branch = "master" alwaysPull = true alwaysRecheck = true }
Nathan
On Apr 7, 2016, at 10:46 AM, Eric Rasche notifications@github.com wrote:
@nathandunn https://github.com/nathandunn I don't completely know.
This was tested on version 076f3a7 https://github.com/GMOD/Apollo/commit/076f3a7227f9a9d061724fb23939339122ca9648 of apollo, which used whatever the default behaviour was for including JBrowse.
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/GMOD/Apollo/issues/970#issuecomment-207022949
Right, but whatever you have in apollo-config.groovy will over-ride what is in Config.groovy. You’ll what to do a master pull so that it uses bower to install jbrowse.
Sorry, was just explaining the particular case I saw this bug--my apollo config did not mention it at all as I was building from the sample-docker-config.groovy
The jbrowse version of your apollo-config.groovy can be commented out (or you can just copy it). What you need is this:
I'll test soon with an updated image and let you know!
git { url= "https://github.com/GMOD/jbrowse" // tag = "1.12.1-release" branch = "master" alwaysPull = true alwaysRecheck = true }
Nathan
On Apr 7, 2016, at 10:46 AM, Eric Rasche notifications@github.com wrote:
@nathandunn https://github.com/nathandunn I don't completely know.
This was tested on version 076f3a7 < https://github.com/GMOD/Apollo/commit/076f3a7227f9a9d061724fb23939339122ca9648> of apollo, which used whatever the default behaviour was for including JBrowse.
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/970#issuecomment-207022949>
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub
@erasche Any luck?
Soonest I'll get to reproduce is monday, sorry
@erasche No worries. No rush, just wanted to make sure you hadn't forgotten to post results. We'll be awhile with this new release.
It looks like the style->color callback is returning an empty string somehow. Nevertheless, there are lots of workarounds and lessons to learn from this bug though
1) The gradient is now gone on jbrowse, so updating to latest jbrowse would fix (addColorStop function from error message was implying gradient trying to be used) 2) We can also comment out NeatCanvasFeatures in the Apollo config file as workaround 3) I would recommend that we maybe not turn on NeatFeatures by default in Apollo. It is not turned on by default in JBrowse either. 4) I think the NeatFeatures should be a tracktype instead code that hijacks every drawing function. That way it can be enabled for specific tracks, and it makes it less error prone.
"4) I think the NeatFeatures should be a tracktype instead code that hijacks every drawing function. That way it can be enabled for specific tracks, and it makes it less error prone."
This method was done as a means to address the fact that dragableHTMLfeatures renders the elements different than HTMLfeatures. I had originally implemented it "inband" but it only worked for HTMLfeatures.
There is mechanism to enable per-track: https://github.com/GMOD/jbrowse/tree/master/plugins/NeatHTMLFeatures
If there is any interest, I could work on adapting the intron rendering specifically for draggableHTMLFeatures.
But, I would like to add back the gradient option for the jbrowse release (when I get around to it). It's still a nice out-of-box experience and looks good in print.
On Fri, Apr 8, 2016 at 8:48 AM, Colin Diesh notifications@github.com wrote:
It looks like the style->color callback is returning an empty string somehow. Nevertheless, there are lots of workarounds and lessons to learn from this bug though
1) The gradient is now gone on jbrowse, so updating to latest jbrowse would fix (addColorStop function from error message was implying gradient trying to be used) 2) We can also comment out NeatCanvasFeatures in the Apollo config file as workaround 3) I would recommend that we maybe not turn on NeatFeatures by default in Apollo. It is not turned on by default in JBrowse either. 4) I think the NeatFeatures should be a tracktype instead code that hijacks every drawing function. That way it can be enabled for specific tracks, and it makes it less error prone.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/GMOD/Apollo/issues/970#issuecomment-207489032
WRT to 3/4) I think the consensus was that we wanted that to be the default for Apollo. I have no opposition to it becoming a track type, as well, but it should be the default for any Genomic Feature. Longer-term I want to see if its possible to ditch HTMLFeatures / NeatFeatures in favor of SVGFeatures / NeatFeatures and render everything natively and more efficiently.
WRT to gradients, yeah, I think it would be a good idea to add it back as an option per track (though not default . . . or if default, it can somehow inherit the colors), which is why I only commented it out.
I want to see if its possible to ditch HTMLFeatures / NeatFeatures in favor of SVGFeatures / NeatFeatures and render everything natively and more efficiently.
I'm not sure I understand the efficient/speed claims. SVG can enable cool things, but it is in most applications slower. Maybe you are not referring to canvas either, but there are lots of documented cases of platforms switching from SVG to canvas for better optimization purposes. pileup.js http://www.hammerlab.org/2015/10/13/svg-canvas-the-pileup-js-journey/ and cytoscape.js https://groups.google.com/forum/#!topic/cytoscape-discuss/bEgh67aw1BI are good examples of platforms that made that switch. I think SVG obviously has areas where it enables cool things, but it doesn't solve everything.
Also, as far as making it the default, my feeling is that people spend a lot of time making their genome browsers look very customized for their tracks. @erasche definitely did for the BLAST tracks for example. I think that overriding their styles is problematic.
So, there are a couple of points here:
1 - the current NeatFeatures draws SVG elements over HTMLFeatures after a milestone so it does some kind of weird jaggediness. It would be much more sense to add the SVG plugin over an SVGFeature track.
2 - SVG is slower than Canvas. If you don't require easy interaction or draggability, Canvas is probably going to be your better bet. However, once you start wanting to do multiple layers and easily attach elements SVG makes more sense.
3 - SVG is faster than DIVs (what I'm arguing here): http://stackoverflow.com/a/5883032/1739366
I'm not proposing never using Canvas, but I think that SVG is more extensible for the more interactive tracks. Obviously we need to set that up to be pluggable which is easy in Apollo (just remove those plugins in the config and add your own). I don't think the plugins are included in the tracks by default in JBrowse.
Just wanted to note that we're not going to remove any of the current HTMLFeature tracks, I just want to move the defaults to SVG. Hopefully, though any relevant function / styling in HTMLFeatures (or DraggableHTMLFeatures) can be ported over directly to the newer SVG track type. WRT to Canvas, I think that something like paper.js might make sense syooirtubg drag and drop and layers, but that is a ways away: http://paperjs.org/examples/hit-testing/
There are some other rendering issues with the NeatHTMLFeatures even if it is not throwing obvious javascript errors
For example, on the BRCA example on the Apollo sample browser, the genes end up looking very strange and/or blank
It seems to depend on zoom level
Sorry my last post refers to NeatHTMLFeatures
@erasche Is the initial problem still a problem? If so, please re-open it.
You might need to update apollo and then do an "./apollo clean-all" so that it properly pulls in changes, but it should be fixed.
The problem that @cmdcolin alluded to I added here: https://github.com/GMOD/jbrowse/issues/743
Tested with gmod/apollo:stable
and this looks to be fixed.
Just dumping the error information before class starts:
Gff3 Looks something like this
trackList.json