thedracle

Thanks for the feedback! This was one of the areas where CoScreen was strong.

We will take your feedback and see what we can do.

It's crazy because we dogfood Petal daily, and did so with CoScreen while it was alive... and we absolutely cannot live without it.

I'm in Utah, and Till is in CA, so it's vital to our daily work.

Truly I don't understand how people do remote work or collaboration these days... maybe they don't? Or maybe Zoom/Meet are good enough (I really truly think they aren't, it's an abusive horrible experience every time I am forced to use Zoom or Meet for anything).

There just seems to be something sticky about them, but the people who try a CoScreen, Tuple, Pop, or other tool designed around collaboration I think become converted permanently, but getting people into that funnel is very very hard.

Lol. Yes, all of the Mic-drop crap.

We can work on it. Obviously it's Till and I working on the copy, and unashamedly we are using Claude to help expedite it so we can focus on the fun stuff... but yes, I absolutely hate this crap too.

Haha. I think I know who this is, and I won't out you, and thank you so much for your support over the years!

Maybe you can contribute some of your private innovations upstream to Petal ;)

One of our engineers is working on a very low latency video/audio mode for gaming. The truth is Petal isn't yet as tuned as say CoScreen was for low latency.

It's on our product roadmap to have a mode to support this though.

Some of our engineers have discussed a totally p2p iroh based video transport and other ideas.

LiveKit was the fastest/easiest way to get it to market, and it was something Till and I volunteered to pay for at the moment so we have an off-the-shelf cloud offering that is free and usable.

From that perspective it has worked great.

Better late than never!

Given CoScreen's very recent demise, we felt this space deserved some love still.

Hopefully you try it out some time, and provide feedback.

> when exceptions would add no overhead

Isn't the overhead for C++ exceptions quite significant, especially if an exception is thrown?

Exception handling can also increase the size of the binary because of the additional data needed to handle stack unwinding and exception dispatch.

I think a number of optimizations are made quite a bit more complex by exception handling as well.

Sorry I missed this.

We still aren't using hardware accelerated encoding. It's the last, and biggest contributor to CPU we see after profiling.

Moving to Rust was more of a decision for safety, than for performance, since most of the code we ported to Rust was in C++ already. The good news is we didn't see dramatic differences in performance between C++ and Rust.

Rust has a bunch of highly optimized, fantastic libraries, that helped with testing, profiling, and evaluating hardware acceleration/SIMD.

We will be putting together a blog about our experiences with Rust & C++, that goes into the nitty gritty of the good, the bad, and the ugly of our experiences here.

A great deal of the optimizations came from better profiling, better tooling, and a focus in that area. There is still a ways to go, and we are continuously working on improvements in this area.

Rust has been an incredible tool on reducing the work required to maintain, and change, core components, and we have even been able to have Rust target a static cylib library, and linked it in from a large C++ library.

The really great thing with Rust is it has a very minimal runtime, and integrates well with C++. It's not an all-or-nothing proposition to integrate it into a project. The maturity of the tooling, third party libraries, the build and package system, have been incredibly useful tools.

Jason Thomas, former CoScreen CTO here.

I am an avid Synergy user, and what they have accomplished in terms of direct mouse/keyboard input synchronization is very impressive, and I use it on a daily basis.

I can say however, it's very different than CoScreen and what CoScreen seeks to achieve, and is performed in a technically different manner.

CoScreen injects mouse interaction and keyboard presses directly into a window on OSX (if it isn't a weird type of window like an emulator, or something that captures and handles input on a very low level).

Synergy simulates mouse movements/events directly over windows, interfering with the position/location and current state of the remote cursor. It's much more like a remote mouse-driver for a lack of a better comparison.

In many ways this is more performant, simpler, and works on a wider variety of windows right out of the box.

On another level it interferes more with remote users, and prevents multi-player collaboration.

I definitely could see us producing a mode that is LAN focussed and which provides synergy like behavior, but the current remote collaboration is really geared from a UX perspective around multi-player in CoScreen.

For a full blown Linux client, we haven't yet set that date.

We are working on a headless Linux client that will allow you to stream first pty/terminals, and then windows, into a CoScreen from Linux systems.

It's going to be a very small utility, and we hope to provide access to it by May/June.

This will eventually evolve into a full blown client.

In the meantime we will have a web client which will work on Linux released shortly, it's currently being privately tested within DataDog.