Hacker News Reader

Comment by cududa | Hacker News Reader

I'm aware. I've worked in the space. It isn't as simple as you're making it out.

Sorry but almost 10 years ago I could do this on Xorg where the worst problem is that compositors cannot redirect input (so you had to kludge new events from scratch). I cannot imagine it would take more than _half an hour_ for someone with macOS display compositor experience to implement it.

I cannot imagine it would take more than _half an hour_ for someone with macOS display compositor experience to implement it.

What fools Apple engineering management must be, then!

It probably actually is a quick initial implementation, but like everything else, it needs to be planned, ticketed, developed, tested, and slated for release.

Compositor work isn't tremendously hard when the graphics primitives are already done.

UI state handling and input is a majority of the work from there. I've implemented this work before. A large portion of my background is in compositors and UI primitives.

What's really cool about having window backing layer handles, is you can do all sorts of crazy fun stuff in the office and show off to your coworkers or tech demo that basically will never make it to production because it's totally impractical.

The best example of that which actually did end up in a final product in my opinion was Windows Flip 3D. Totally fun implementation, I'm sure.

And the reason Xorg is now dying in favor of a system that doesn’t have this capability is because the architecture that enabled it, while cool at the time, severely limited the graphics performance and capability of the applications.

What? Doesn't Wayland work this way by design?

Don't be letting actual experience get in the way of shitting on Xorg, now! Wayland will never win with that attitude!

Indeed it does not. It’s local only.

I see. Do you mean like the Xorg fast path for local 3d rendering that became the basis for Wayland?

Exactly that. A local only path that provides high performance.

Remember the original comment was the claim that Xorg could easily do remote windows years ago. This is only true using the low performance path that modern operating systems have universally rejected.

No, the original comment is that by writing an Xorg compositor I could project separate windows into separate surfaces at arbitrary positions in the 3D world. There's no need for network transparency and you can very well do with an HDMI cable (actually, I was using an HDMI cable -- this was 10 years ago).

Network transparency is exactly what people want. If you're going to say just tether it to your computer with a wire then you just aren't understanding the product.

Network transparency is not required for wireless video, either.

I doubt making the windows draw is what’s taking them time to get right.

You nailed it, down to how you'd do it without any help from Cupertino: https://github.com/saagarjha/Ensemble

Except that doesn’t actually do it. It is just a proof of concept.

Try it with a full suite of Mac Apps and you’ll find it falls apart because they aren’t all well behaved.

It falls apart how exactly? There's some app for which the popup menus are not shown at the right coordinates?

You are making this sound much more complicated than it really is.

Amongst many possible edge cases. Not to mention shearing with things that have rapid animations etc.

The trivial case is simple. You are imagining it's all the trivial case.

But they have already fixed shearing, otherwise there would be no MacBook display mirroring feature at all, multiple surfaces or not.

I’m talking about this open source project, not Apple’s implementation.

It's probably more down to the getting the UI right on apple's end.

Unfortunately I happen to live in Cupertino

Yes, it is.

In fact, there's already a project for it on GitHub. https://github.com/saagarjha/Ensemble

480 lines total, including comments, headers, whole shebang.

> Ensemble is currently "pre-alpha": it's really more of a demo at this point. There's a lot of things I need to work on and until then it is unlikely I will be taking any code contributions.... The code is definitely not designed for general-purpose use yet, so don't expect much of it :)

Tech demos are often easy to put together.

It's all of the edge cases and UX refinements that takes time.

Yeah, sure. I'm gonna go ahead and say Apple probably could have found a way to ship this over the visionOS dev cycle.

Some of the code is factored out into individual libraries. For example the networking and serialization code is separate and it is likely that screen recording will get pulled out too at some point.

Reply on news.ycombinator.com