This doesn't have to be a full desktop, it could be a single window application such as Napari. The desktop you see in the browser is NoVNC, which connects to the websocket. Instead the VNCserver running in Jupyter is wrapped by websockify which is a library that converts a TCP stream into a websocket that can be handled by JavaScript in the browser. The more complex explanation: VNC requires TCP traffic which can't be sent direct to a browser.
They both use jupyter-server-proxy to proxy VNC to the browser. None of this really matters for our more immediate remote goals, but it's just interesting :) and potentially a short-term workaround for some users who really want napari to work in remote desktop is a fork of that provides a generic desktop (so for example my Napari demo could be built on top of it, as could many other desktop apps). teamviewer) would work too and we just haven't tested them yet. It's also completely possible that other solutions (e.g. not really sure what to do with that info. there is also discussion about ANGLE in the qt wiki.Īgain. Perhaps related (but I'm not really sure), is the ANGLE library from google which appears to be a layer between OpenGL ES API calls and platform-specific hardware APIs. I don't really understand why, and googling it hasn't really turned up anything obvious. Interestingly, napari works just fine using google chrome remote desktop. ≤1.4) that are incompatible with vispy, and QWindow rendering using openGL. My limited understanding is that the way it is implemented generally limits openGL to older versions (e.g. File this under potentially interesting rainy day information that doesn't really require any immediate action, but which has implications for remote GL-based rendering.Īs has been mentioned elsewhere, openGL has issues with virtualized desktops, making things like microsoft remote desktop, x11 forwarding on *nix, and (sometimes) tests on our CI fail.
0 kommentar(er)
