#241 IGB slice graph rendering bug
Hello Folks,
Think I've found a rendering bug in the new IGB 6.7.0. Download the test files from here http://bioserver.hci.utah.edu/TempFiles/StairStepRenderingBugTestFilesNix.zip Take a look at the screen shots.
In brief, sometimes the stair step graph renders fine, sometimes a big parallel block extend rightward after the last graph block when zooming in or out and loading more data slices from a xxx.useq stair-step graph.
To reproduce:
1) unzip the archive from above
2) open the testRegion.html in a web browser
3) launch IGB 6.7.0
4) click the Test Region M_musculus_Jul_2007, chr1:24616416, 24624985 book mark html link
5) drag in the BinPVal.useq file onto IGB
6) hit load data, should look ok, nice 4.5 kb block
7) zoom out, hit load data,
8) zoom in and out and watch for the odd right side rendering block starting off the end of the 4.5 block, you might need to zoom in and out and hit load data a few times
It's rather a bother since it obscures the real size of the graph.
When converting to ucsc bw, I don't see this but then again the bw graphs are not rendered as stair step graphs.
Discussion
I'm seeing this with IGB 6.6.3 too.
hi David,
This is apparently an artifact of how IGB draws the stair step (and the line) graph... IGB uses a continuous graph for these two styles, so that if you load an 'island' of data, and then a second 'island' of data a distance away, the graph will be drawn with a connecting bar or line. The problem arises when the 'terminal values' are non-zero; if the end of one island is '10' and the start of the next island is '30', you will see a stair step of at least 10 high between them. For the line style, there will be a rising line connecting the two 'islands'. This connector section seems to become visible at different zoom levels.
While this is NOT a bug, as in the behavior is expected, it is irritating when you are working with these graphs... I have also reported this issue before (I had problems with the line graphs). One suggestion I have made recently is that perhaps in unloaded regions the values be set to '0' so that although the graph is continuous, you just don't see it...
So until a decision about how to address this issue is made, I would recommend one of the other graph styles, perhaps min/max/mean?
Alyssa
Thanks Alyssa for the tips.
This is a major problem for us. I've been doing a fair bit of digging this afternoon....
I don't think it is an island issue. It's a rendering bug. If you reboot and load up that example I described, and slowly zoom out/ hit load, zoom out/ hit load, ditto, eventually the right block appears even on a new launch of IGB with no other adjacent upstream or downstream islands loaded.
I tried some of the other graph styles. The Min/Max/Avg doesn't fill in the blocks, the line graph as you mentioned does exactly what the stair-step graph does.
Looking at the graph in bar style seems to have revieled the problem. On the first load (reboot IGB and hit the Test Region link in the html doc), IGB shows the 0 value points I put in the stair step graphs to bracked each block. For example, here's the right side boundary of the block in question and one downstream:
....
chr1 24623030 414.1525
chr1 24623035 414.1525
chr1 24623036 399.58456
chr1 24623050 399.58456
chr1 24623051 371.9166
chr1 24623056 371.9166
chr1 24623057 369.56998
chr1 24623059 369.56998
chr1 24623060 362.14236
chr1 24623062 362.14236
chr1 24623063 0.0
chr1 24686158 0.0
chr1 24686159 5.0852456
chr1 24686216 5.0852456
chr1 24686217 0.0
As one zooms out and hits 'Load Data', repeat, all is OK but eventually the right side 0 value disappears or is effectively deleted, but not the left side. Odd. The right side zero point never comes back, even when zooming back in. (Note, it also isn't an issue of the left side seeing a data point first; deleting this doesn't cause the left side to get a block its only the right side.)
I tried replacing all of these boundary 0.0's with 5's but see the same behavior as with the 0's.
This happens regardless of the graph type. If I build the useq file as a bar graph style, and then do the slice load, zoom out, load, zoom out in bar graph style, the right side point disappears.
I even loaded up the data into our DAS/2 server as bar files and see the same behavoir when loading slices of data. Thus, it's not related to useq format.
So I don't think the problem is with unloaded regions between islands, it's in the non rendering/ deletion of right side boundary points.
Any suggestions? We've got literally thousands of the stair-step graph files being served via DAS/2.
-cheers, D
Hello Folks,
I've renamed the Summary, and posted another test dataset to: http://bioserver.hci.utah.edu/TempFiles/SliceRenderingBug.zip
This contains an sgr graph from mm9 chr1. (Load it in bar graph style.) And a picture showing the disappearing 3' end data point upon loading of subsequent graph slices.
Follow the directions below and watch how it goes missing. The problem isn't confined to stair-step graphs as I originally though, but appears to be due to rendering additional graph slices as one zooms out.
Can someone take a look at this ASAP? Let me know how I can help.
-cheers, D