Use round numbers for the figure size

[martinRenou]

This has a side-effect to prevent useless relayout calls due to getBoundingClientRect precision issues.

It improves performances in the case of having a plot in a tooltip: sometimes the clientrect width is evaluated to 334.023456 pixels, sometimes 334.0235432535 pixels, causing a useless relayout.

[maartenbreddels]

I'm not sure we should do this, with high-dpi/retina screens, DOM sizes are floats.

[martinRenou]

I understand DOM sizes are floats. But nobody will see the difference between a 334 pixels width plot and a 334.0235432535 pixels width plot.

Why do you think it would be a problem?

[maartenbreddels]

A hunch that this will gives issues/confusion in the future when our size != DOM size. I agree you wouldn't see the difference, but I'm afraid this will be a source of new bugs. I think the clientrect should not change, we may be doing something wrong with the tooltip.

[martinRenou]

A hunch that this will gives issues/confusion in the future when our size != DOM size

I doubt it actually. Because the output of this.el.getBoundingClientRect changes because of precision issues. Sometimes it returns 334.023456, sometimes it returns 334.0235432535, resulting in useless relayout calls which cost a lot.

[martinRenou]

I think we should at least truncate it to 10^-2

[maartenbreddels]

Man, this is annoying behaviour. Is this a browser bug or is this well known/documented? I don't mind so much the truncation, but I mind more the fact that they aren't equal. But truncating to 2 decimals sounds better.

[SylvainCorlay]

I the inacurracy of getBoundingClientRect a known fact, or are we seeing an actual bug (css rul causing it to change by a fraction of a pixel)?

[martinRenou]

In the case of the tooltip with a plot in it, we hardcode a default size: https://github.com/bqplot/bqplot/blob/master/js/less/bqplot.less#L298. So I am not sure the CSS rules are complicated enough to result in this kind of behaviors (I gave 334.023456 as an example of what I can get but I guess it was more like 427.023456).

Hence I am tempted to say it's a browser issue? I am using Google Chrome.

I guess my point is that it does not really make sense to use fractions of pixels anyway. In which case would it make sense to use fractions of pixels?

[jasongrout]

FYI, a CSS pixel is not the same as a device pixel: https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel, https://hacks.mozilla.org/2013/09/css-length-explained/, https://drafts.csswg.org/css-values-3/#absolute-lengths

[jasongrout]

For example, here is what I get on a hidpi screen (with device pixel ratio of 2):

<div class='red rect'>
</div>
<div class='blue rect'>
</div>
<style>
.rect {
  width: 100px;
  height: 100px;
  position: absolute;
  border: 1px solid;
}
.red {
  border-color: red;
  top: 100px;
  left: 100px;
}
.blue {
  border-color: blue;
  top: 100.5px;
  left: 100.5px;
}
</style>

Look very closely and you'll see that those boxes are not on top of each other.

[jasongrout]

You can also get a devicePixelRatio different than 1 or 2 by zooming in your browser.

But perhaps this suggests that rounding to the nearest tenth or hundredth is more than sufficient for our current generation of devices.

[martinRenou]

Thanks for the link and the example @jasongrout.

[martinRenou]

I've been making some tests locally. Most of the times I get a tooltip size of

426.99609375 x 319.9921875

But sometimes I get

426.99615478515625 x 319.9921875
# or
426.99609375       x 319.99224853515625
# or 
426.99615478515625 x 319.99224853515625

The weird thing is that those numbers don't really seem to be random. It's like I can only get two different values for the width, and two different values for the height.

Any idea on what could cause this?

If we actually truncate the values, it seems like rounding to the nearest hundredth would work. But that was only tested on my browser, maybe other browsers would act differently.