Dynamic range issue when updating data on ScatterGL

[astrofrog]

When updating x or y on a ScatterGL mark, the display will not look good if the new values are at a significantly different order of magnitude compared to the original values.

The following example demonstrates the issue:

import numpy as np
from bqplot import (
    Axis,
    LinearScale,
    ScatterGL,
    Figure,
    PanZoom,
)
from IPython.display import display

sc_x = LinearScale()
sc_y = LinearScale()

scatt = ScatterGL(
    x=np.linspace(98.3, 98.4, 100),
    y=np.linspace(1e6, 2e6, 100),
    scales={"x": sc_x, "y": sc_y},
)
ax_x = Axis(scale=sc_x, label="x")
ax_y = Axis(scale=sc_y, orientation="vertical", tick_format="0.0f", label="y")
panzoom = PanZoom(scales={"x": [sc_x], "y": [sc_y]})

figure = Figure(marks=[scatt], axes=[ax_x, ax_y])
display(figure)

y = np.random.uniform(0.9, 1.1, 100)
y[0] = np.nan
scatt.y = y

sc_y.min = 0.0
sc_y.max = 2.0

If run in a notebook in a single cell, this gives:

The values appear to be discretised. Showing the figure in a new cell works fine:

[astrofrog]

@maartenbreddels - just for the record as I think you originally implemented ScatterGL?

[maartenbreddels]

I have trouble reproducing this. Which versions of bqplot and jupyter (notebook or lab?) are you using?

I wonder if it could be a hardware issue, do you see the same issue on PyCafe

(If so, it could be a hardware issue)

[rosteen]

I was on:

jupyterlab 4.2.5
bqplot 0.12.43
bqplot-gl 0.0.0
bqplot-image-gl 1.5.0

Did you try running the LCViz example notebook? That's also a way to reproduce (the flattening step leads to a flat featureless plot at 1, see the LCViz issue linked above).

[astrofrog]

It works fine for me on PyCafe but not in Jupyter Lab locally (on the same machine)

[maartenbreddels]

Apparently this depends on the hardware as I found out using this example

(now with the button, we make the change happen somewhat later).

This shows the aliasing on a M1 Pro, but not on a M1 Max (which I have).

    vec3 center = mix(vec3(x_previous, y_previous, 0), vec3(x, y, 0), animation_time);

On some hardware, even when animation_time is 0, the magnitude of y_previous had an effect on center.y!

I should have a fix out early next week.

[rosteen]

Interesting, thanks for the update!