OK I got the basics down for lines. One caveat is that now there's no check to make sure that the buffer sizes match for data and colors for example.

Consider this:

lg = subplot.add_line(np.random.rand(100))
lg.data = np.random.rand(200)

Now the last 100 line points are just black since they're not defined. A user has to explicitly set the colors of the new vertices that extend beyond the previously defined buffer.

lg.colors = ["w"] * 200

Or they can use a uniform color for things like this.

ok for images I think easiest way is to create new world objects 🤔

EDIT: Yup this will be fine, I was initially worried that we'd have to re-add event handlers if we create a new world object, but I don't think that's necessary since ImageGraphic and ImageVolumeGraphic use a pygfx.Group as the world object, so we can just clear the group and add new image tiles.

EDIT again: Just tested with image click events, if an event handler is added to the graphic then when new tiles are created the graphic is still responsive to those events because it's the pygfx.Group that is handling the events and not the individual image tiles.

@clewis7 would like to get your review before I do the gc tests

📚 Docs preview built and uploaded! https://www.fastplotlib.org/ver/replaceable-buffers

I think we should make uniforms the default for all graphics 🤔.

Also good time to start a "performance tips" section of the docs. Replacing the buffer has a huge performance hit so you don't want do it all the time.

I found a memory leak, if old_buffer._wgpu_object.destroy() is not called then it lingers on in GPU VRAM even if the Binding object no longer exists.

Posted on pygfx: pygfx/pygfx#1264

For now I implemented manually destroying the GPUBuffer when it's replaced.

@clewis7 what do you think about:

For lines, default is:
uniform_colors = True

For scatters, default is:
uniform_colors = False

I think independent scatter colors is a more common usecase than lines. We can auto-determine it in the future based on the colors and cmap arg but I'll do that in the future.

EDIT: But then the API is inconsistent between lines and scatters :/

OK I got the basics down for lines. One caveat is that now there's no check to make sure that the buffer sizes match for data and colors for example.

Consider this:

lg = subplot.add_line(np.random.rand(100))
lg.data = np.random.rand(200)

Now the last 100 line points are just black since they're not defined. A user has to explicitly set the colors of the new vertices that extend beyond the previously defined buffer.

lg.colors = ["w"] * 200

Or they can use a uniform color for things like this.

I think this behavior is confusing. Perhaps it is better to just by default take the current color scheme and extend it to the new or fewer points.

@clewis7 what do you think about:

For lines, default is: uniform_colors = True

For scatters, default is: uniform_colors = False

I think independent scatter colors is a more common usecase than lines. We can auto-determine it in the future based on the colors and cmap arg but I'll do that in the future.

EDIT: But then the API is inconsistent between lines and scatters :/

Hmmm, I do agree that scatters are more likley to have individual colors. How much a performance reduction is it if you make the lines also have uniform_buffer=True as the default??