Bug? Question about synchronicity contract of JupyterRenderCanvas

[tlambert03]

Hey @almarklein

While working with rendercanvas.jupyter.JupyterRenderCanvas in ndv, I found that all scene updates appears to be one step behind my interactions. So, for example, if I toggle a checkbox to hide one of the objects in the scene, or change the data in a texture, the immediate result of the interaction is to render the state resulting from the previous interaction.

The workaround I came up with was:

class JupyterRenderCanvas(rendercanvas.jupyter.JupyterRenderCanvas):
    def get_frame(self) -> Any:
        self._process_events()
        self._draw_and_present(force_sync=True)
        return self._last_image

however, I suspect I'm not quite understanding the contract of the ABC there. Can you help me understand? is get_frame() designed to be asynchronous? Is this likely a bug in how I'm invoking request_draw(animate)? (fwiw, my request_draw pattern is working fine in Qt and Wx, it's just the jupyter backend that is one-step-behind... And furthermore: it's only in pygfx; vispy going through jupyter-rfb seems fin)

[almarklein]

Hey @tlambert03! I assume this is with the latest release? It should be fixed in main.

This is indeed a regression introduced by the async bitmap present; at the moment that the bitmap is downloaded, it was not actually pushed to the client. This only happened on a new frame.

This has been fixed in #198 (and #200 has the fix too)

[tlambert03]

Ah! Fantastic, thanks!