Thanks! I've been doing a lot of work on a laptop screen (I normally work on an ultrawide) and got tired of constantly switching between windows to find the information I need.

I've also added the ability to create a picture-in-picture section of any application window, so you can move a window to the background while still seeing its important content.

I'll probably do a Show HN at some point.

Unless you worked on the macOS content server directly you’d have no idea that my solution was even possible.

That fact that Claude skipped over all the obvious solutions is why I used the word novel.

Because you can't control what the content server is doing. SCK doesn't care if you only need a small section of a window: it performs multiple full window memory copies that aren't a problem for normal screen recorders... but for a utility like mine, the user needs to see the updated content in milliseconds.

Also, as I mentioned above, when using SCK, the user cannot minimize or maximize any "watched" window, which is, in most cases, a deal-breaker.

My solution runs at under 2% cpu utilization because I don't have to first receive the full window content. SCK was not designed for this use case at all.

Well, I'm not going to share either solution as this is actually a pretty useful utility that I plan on releasing, but the short answer is: 1) don't use ScreenCaptureKit, and 2) take advantage of what CGWindowListCreateImage() offers through the content server. This is a simple IPC mechanism that does not trigger all the SKC limitations (i.e., no multi-space or multi-desktop support). In fact, when using SKC, the user cannot even minimize the "watched" window.

Claude realized those issues right from the start.

One of the trickiest parts is tracking the window content while the window is moving - the content server doesn't, natively, provide that information.