As of now, node-syphon requires hacks on user's javascript implementation side to work in parallel threads (workers).
Client: until we find a way to avoid downloading GPU texture to CPU data, we should refactor the way client is handled in the addon itself, by
- Providing single source of truth for a given server subscription, whatever how many subscribers are involved (currently done on javascript-side).
- Consequently handling the frame bufferization in a threadsafe kind of 'server store'.
- Transparently providing the javascript-side client with a shared and 'worker-ready' frame on 'frame' event listener.
As by doing this, we would... just mirror the way Syphon works, but in a kind of still hacky memory-sharing of pixels and not texture / IOSurface, I guess we could at least handle this pixels sharing in a threadsafe way so destination canvases, video encoders, etc., GPU to CPU download and pixels writing would not affect the application itself.
As of now,
node-syphonrequires hacks on user's javascript implementation side to work in parallel threads (workers).Client: until we find a way to avoid downloading GPU texture to CPU data, we should refactor the way client is handled in the addon itself, by
As by doing this, we would... just mirror the way Syphon works, but in a kind of still hacky memory-sharing of pixels and not texture / IOSurface, I guess we could at least handle this pixels sharing in a threadsafe way so destination canvases, video encoders, etc., GPU to CPU download and pixels writing would not affect the application itself.