floating-point rounding compensation to range-item width (#2092)

[Iskander508]

No description provided.

[mojoaxel]

@Iskander508 Thanks very much! It looks like it works.
Just for my understanding: It looks to me like the box-width is now rounded up every time. Can this not result in an overlap of 1px sometimes?

[Iskander508]

Yes, that's right, neighboring ranges can overlap by 1 pixel. It is not the cleanest solution for sure.
The overlapping could happen even in the old version in some cases.
e.g.:
range A: start 0.7, end 2.4
range B: start 2.4, end 3.4

A:
start: 0.7 => 1
width: 2.4 - 0.7 = 1.7 => 2
end: => 3

B:
start: 2.4 => 2
width: 3.4 - 2.4 = 1.0 => 1
end: => 3

B is completely overlapped by A, no compensation used.

[yotamberk]

@mojoaxel this merge causes #2318. I don;t understand this PR and what it solved. Can you explain?
If this PR is important and we don't want to revert, we can solve #2318 by subtracting 0.5 a pixel in the start time.

[mojoaxel]

@yotamberk This was a fix for #2092 . It basically numerically rounds up the item-width. It's very possible that this causes #2318 , but I see no good way to deal with that kind of numerical inaccuracy.

[yotamberk]

@mojoaxel no problem. Now it's clear to me the importance of this PR.
There are way to overcome the overlapping as mentioned in the issue #2318