6 ms·
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 sc
by AshamedCaptain 3y ago
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.
- refulgentis 3y agoYou nailed it, down to how you'd do it without any help from Cupertino: https://github.com/saagarjha/Ensemble https://github.com/saagarjha/Ensemble
- sleepybrett 3y agoIt's probably more down to the getting the UI right on apple's end.
- kj99 3y agoExcept 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.
- AshamedCaptain 3y agoIt 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.
- kj99 3y agoAmongst 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.
- AshamedCaptain 3y agoBut they have already fixed shearing, otherwise there would be no MacBook display mirroring feature at all, multiple surfaces or not.
- kj99 3y agoI’m talking about this open source project, not Apple’s implementation.
- saagarjha 3y agoUnfortunately I happen to live in Cupertino
- wharvle 3y agoI doubt making the windows draw is what’s taking them time to get right.
- glhaynes 3y agoI 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!
- NoPedantsThanks 3y ago[dead]
- andrewmcwatters 3y agoIt 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.
- kj99 3y agoAnd 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.
- ubercow13 3y agoWhat? Doesn't Wayland work this way by design?
- kj99 3y agoIndeed it does not. It’s local only.
- ori_b 3y agoI see. Do you mean like the Xorg fast path for local 3d rendering that became the basis for Wayland?
- kj99 3y agoExactly 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.
- AshamedCaptain 3y agoNo, 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).
- kj99 3y ago