Not possible to enter exact coordinate range #341

Closed
keiranmraine opened this Issue Sep 9, 2013 · 8 comments

Comments

Projects
None yet
4 participants
@keiranmraine
Contributor

keiranmraine commented Sep 9, 2013

Hi,

We were just trying to display exactly the same coordinate range in 2 different browsers as we were attempting to compare the render time and found that the entered range is always padded even when quite large.

For example entering:
12:25355934..25367556
Results in a display range of:
12:25354711..25368780

Although I can see it is sensible for small ranges to be padded to a sensible display it's possibly less useful at larger ranges.

Could the behaviour be modified to prevent this once the display is over say 70 b.p.

Thanks,

Keiran

@keiranmraine

This comment has been minimized.

Show comment
Hide comment
@keiranmraine

keiranmraine Sep 9, 2013

Contributor

Under chrome the range doesn't seem to be modified, under Safari it changes so not really sure what the expected behaviour is.

Contributor

keiranmraine commented Sep 9, 2013

Under chrome the range doesn't seem to be modified, under Safari it changes so not really sure what the expected behaviour is.

@rbuels

This comment has been minimized.

Show comment
Hide comment
@rbuels

rbuels Sep 9, 2013

Collaborator

There are a couple of causes behind this.

JBrowse zoom levels (pixels per basepair) are discrete, so that data
fetches and sometimes renderings can be cached.

And, the location box right now tries to always display the exact range
of basepairs that is visible in the browser right now.

So, the only way to get the exact same display range in two different
browsers is for the widths of the two display windows, in pixels, to be
exactly the same.

Would it be better for the location box to lie to you about what range
is being displayed?

Collaborator

rbuels commented Sep 9, 2013

There are a couple of causes behind this.

JBrowse zoom levels (pixels per basepair) are discrete, so that data
fetches and sometimes renderings can be cached.

And, the location box right now tries to always display the exact range
of basepairs that is visible in the browser right now.

So, the only way to get the exact same display range in two different
browsers is for the widths of the two display windows, in pixels, to be
exactly the same.

Would it be better for the location box to lie to you about what range
is being displayed?

@keiranmraine

This comment has been minimized.

Show comment
Hide comment
@keiranmraine

keiranmraine Sep 9, 2013

Contributor

I'm not too bothered if it is slightly different and there is a reason for it. I suppose we're quite used to GBrowse giving the exact range.

A concern is how much of a difference I'm getting, an additional 2-3kbp seems extreme when viewing over 10kbp. If you are viewing deep bam files that's quite a large difference in data.

Contributor

keiranmraine commented Sep 9, 2013

I'm not too bothered if it is slightly different and there is a reason for it. I suppose we're quite used to GBrowse giving the exact range.

A concern is how much of a difference I'm getting, an additional 2-3kbp seems extreme when viewing over 10kbp. If you are viewing deep bam files that's quite a large difference in data.

@rbuels

This comment has been minimized.

Show comment
Hide comment
@rbuels

rbuels Sep 9, 2013

Collaborator

That does seem excessive. Are you able to make a similar thing happen
with the volvox example data? If I can reproduce it there, I can see if
I can tweak things to tighten it up a bit.

Collaborator

rbuels commented Sep 9, 2013

That does seem excessive. Are you able to make a similar thing happen
with the volvox example data? If I can reproduce it there, I can see if
I can tweak things to tighten it up a bit.

@Erik-J-D

This comment has been minimized.

Show comment
Hide comment
@Erik-J-D

Erik-J-D Sep 20, 2013

Contributor

Fri Sep 20 08:34:24 2013: Erik-home: the root cause, really, is the inaccurate html layout in safari
Fri Sep 20 08:34:48 2013: (i.e. not handling fractional position percentages very precisely)
Fri Sep 20 08:35:13 2013: looking now
Fri Sep 20 08:35:40 2013: Erik-home: however, if the Sequence track were modified to render bases differently (instead of just lining elements up), it could probably sidestep that.
Fri Sep 20 08:36:08 2013: like, each line of sequence could maybe be a

with 100% width
Fri Sep 20 08:36:20 2013: that would probably fix things
Fri Sep 20 08:36:41 2013: (100% width and one row)
Fri Sep 20 08:41:04 2013: rbuels: I'll give it a shot, where is the rendering stuff?
Fri Sep 20 08:41:16 2013: Erik-home: JBrowse/View/Track/Sequence.js

[10:54] @rbuels Erik-home: while you're working on Sequence.js, would you mind renaming the "aa" CSS class to "amino_acid" in the .js and the CSS?
[10:54] @rbuels i just noticed that just "aa" can collide with "ancestral allele" in vcf files
[10:59] rbuels, did you happen to document exactly what rendered wrong in your b9eb629 fix?
[10:59] it looks fine when I remove the check for inaccurate-html
[11:00] But I don't know how to tell for sure
[11:03] @rbuels Erik-home: i believe the main thing was that at some zoom levels, Sequence tracks ("Reference sequence" in the volvox test data) rendered badly
[11:03] @rbuels in safari
[11:10] rbuels, reproduced on 5.1
[11:22] I can't reproduce it consistently, it's very, very picky about the exact zoom level
[11:25] @rbuels Erik-home: in that case, leave your window size the same, and copy the region string to your clipboard
[11:25] @rbuels Erik-home: but yes, it only happens at some zoom levels
[11:25] noted
[11:26] @rbuels Erik-home: which is why that thing fixed it: if on safari, it forces the zoom level to one of the predefined ones
[11:26] @rbuels thus leading sometimes to big discrepancies in what you put in
[11:29] @rbuels bleh
[11:29] @rbuels Erik-home: i think the better fix, then, would be to make Sequence.js render each line as a table

Contributor

Erik-J-D commented Sep 20, 2013

Fri Sep 20 08:34:24 2013: Erik-home: the root cause, really, is the inaccurate html layout in safari
Fri Sep 20 08:34:48 2013: (i.e. not handling fractional position percentages very precisely)
Fri Sep 20 08:35:13 2013: looking now
Fri Sep 20 08:35:40 2013: Erik-home: however, if the Sequence track were modified to render bases differently (instead of just lining elements up), it could probably sidestep that.
Fri Sep 20 08:36:08 2013: like, each line of sequence could maybe be a

with 100% width
Fri Sep 20 08:36:20 2013: that would probably fix things
Fri Sep 20 08:36:41 2013: (100% width and one row)
Fri Sep 20 08:41:04 2013: rbuels: I'll give it a shot, where is the rendering stuff?
Fri Sep 20 08:41:16 2013: Erik-home: JBrowse/View/Track/Sequence.js

[10:54] @rbuels Erik-home: while you're working on Sequence.js, would you mind renaming the "aa" CSS class to "amino_acid" in the .js and the CSS?
[10:54] @rbuels i just noticed that just "aa" can collide with "ancestral allele" in vcf files
[10:59] rbuels, did you happen to document exactly what rendered wrong in your b9eb629 fix?
[10:59] it looks fine when I remove the check for inaccurate-html
[11:00] But I don't know how to tell for sure
[11:03] @rbuels Erik-home: i believe the main thing was that at some zoom levels, Sequence tracks ("Reference sequence" in the volvox test data) rendered badly
[11:03] @rbuels in safari
[11:10] rbuels, reproduced on 5.1
[11:22] I can't reproduce it consistently, it's very, very picky about the exact zoom level
[11:25] @rbuels Erik-home: in that case, leave your window size the same, and copy the region string to your clipboard
[11:25] @rbuels Erik-home: but yes, it only happens at some zoom levels
[11:25] noted
[11:26] @rbuels Erik-home: which is why that thing fixed it: if on safari, it forces the zoom level to one of the predefined ones
[11:26] @rbuels thus leading sometimes to big discrepancies in what you put in
[11:29] @rbuels bleh
[11:29] @rbuels Erik-home: i think the better fix, then, would be to make Sequence.js render each line as a table

@rbuels

This comment has been minimized.

Show comment
Hide comment
@rbuels

rbuels Sep 27, 2013

Collaborator

Fix for this is in the safarifix branch: http://github.com/gmod/jbrowse/compare/master...safarifix

Collaborator

rbuels commented Sep 27, 2013

Fix for this is in the safarifix branch: http://github.com/gmod/jbrowse/compare/master...safarifix

@rbuels rbuels closed this in 9b4dcf9 Sep 27, 2013

rbuels added a commit that referenced this issue Sep 27, 2013

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin May 5, 2014

Contributor

I am not sure if it is known, but I am seeing a small rendering issue on Safari (on both low res or retina display) that seems to have been introduced in 1.10.5 here

bug2
Screenshot of JBrowse 1.11.3 with rendering issue

This bug happens when you are at an arbitrary zoom level and it seems to reappear and disappear based upon horizontal scrolling

Contributor

cmdcolin commented May 5, 2014

I am not sure if it is known, but I am seeing a small rendering issue on Safari (on both low res or retina display) that seems to have been introduced in 1.10.5 here

bug2
Screenshot of JBrowse 1.11.3 with rendering issue

This bug happens when you are at an arbitrary zoom level and it seems to reappear and disappear based upon horizontal scrolling

@Erik-J-D

This comment has been minimized.

Show comment
Hide comment
@Erik-J-D

Erik-J-D May 5, 2014

Contributor

Oh god, this bug... It's a pixel rounding issue in some browsers that makes
those segments short a pixel, I thought me and/or Rob fixed it by switching the
affected divs to table. That fixed it (at the time, it seems), if I recall.

Erik

On May 5, 2014 at 6:16 PM Colin notifications@github.com wrote:

I am not sure if it is known, but I am seeing a small rendering issue on
Safari (on both low res or retina display) that seems to have been introduced
in 1.10.5 here

[bug2]
https://cloud.githubusercontent.com/assets/6511937/2883900/f0b90ffe-d4a1-11e3-918b-4e381efc922d.png
Screenshot of JBrowse 1.11.3 with rendering issue

This bug happens when you are at an arbitrary zoom level and it seems to
reappear and disappear based upon horizontal scrolling


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

Contributor

Erik-J-D commented May 5, 2014

Oh god, this bug... It's a pixel rounding issue in some browsers that makes
those segments short a pixel, I thought me and/or Rob fixed it by switching the
affected divs to table. That fixed it (at the time, it seems), if I recall.

Erik

On May 5, 2014 at 6:16 PM Colin notifications@github.com wrote:

I am not sure if it is known, but I am seeing a small rendering issue on
Safari (on both low res or retina display) that seems to have been introduced
in 1.10.5 here

[bug2]
https://cloud.githubusercontent.com/assets/6511937/2883900/f0b90ffe-d4a1-11e3-918b-4e381efc922d.png
Screenshot of JBrowse 1.11.3 with rendering issue

This bug happens when you are at an arbitrary zoom level and it seems to
reappear and disappear based upon horizontal scrolling


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

cmdcolin added a commit that referenced this issue May 6, 2014

Fixed rounding errors by using min-width and max-width instead of wid…
…th:100% on safari. Safari is fixed but chrome still has small errors on high resolution screen. Chrome is fine on regular resolution screen. Firefox never had a problem. See issue #341 for old rehash of this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment