What is your use case for screensharing without audio? I can't figure out when that would be useful, you have to communicate with the other person somehow.
There are many. For example, you're leaving your home computer and going to work. Save a link and see what's going on there. The same for remote desktops.
Another use case if when you have a long-running meeting, and still need to share. I found I sometimes just do not sit and listen for those 1-2 hours meetings, but prefer to code.
And for those of us who just don't like audio, like myself. I have many students who I am willing to help, but I don't wanna get audio-involved. My voice chat is not a very parallelable resource.
VNC doesn't even share your screen, it creates its own offscreen screen and doesn't even load your desktop, and uses some unusable minimalist window manager with a stupid X cursor. Yeah I could probably figure out how to get it to work but it's a chore. Terrible product design.
I've been wanting to create something WebRTC based, I'm not happy with either VNC or RDP.
On Windows, you do share the screen. I haven't seen any VNC servers that give you a new session like Terminal Services would.
On Linux, I've used both kinds of VNC server. One does start a new X instance, while the other one shares your main X instance. At the time I tried it, it was "TightVNCServer" to get a new X instance, and "X11vnc" to share the existing session.
Monitoring a remote machine makes a lot of sense. I'm still not totally getting how it can work for live collaboration, but if it works for you that's great. I do love the minimalist efficiency.
I don't think it's meant for live collaboration. Given that the OP is pretty focused on overcoming time restrictions, all-day remote machine monitoring seems like exactly the kind of use case they had in mind.
I think adding audio would open interesting use cases though. People hate video, but 1fps isn't video. Audio still feels like an compelling feature. IMO..
> 1fps.video is perfect for introverts and remote workers who prefer sharing their screen without the pressure of audio or video calls. It's a versatile solution that works alongside any team chat application you're already using.
It seems closer to "text chat while sending screenshots" than "share screen in a voice call." I can see why some would prefer this.
I get that, but it's also designed for sharing your entire laptop screen, so you'd have to either switch back and forth between code and chat, or take up half the screen with your chat app, both of which seem like they would be pretty disruptive to the actual screensharing.
It seems like it would be better to just send a screenshot and then discuss, so the other person doesn't have to watch you typing messages to them instead of looking at the actual thing you want to share.
that's what I thought as well, but then I read this part:
> we use WebSocket-based cursor tracking, providing smooth, near 30 FPS pointer movement for precise demonstrations.
This part does not seem to support that use case, you don't need 30 FPS pointer tracking for text chat.. Moreover, it'd be actively bad, as the cursor is likely to be pointing to the text chat window.
