New Xquartz release with native Apple Silicon support(mail-archive.com)
mail-archive.com
New Xquartz release with native Apple Silicon support
https://www.mail-archive.com/[email protected]/msg01027.html
41 comments
> Annoyingly high input and redisplay latency (probably not fixable, just an inherent property of the very chatty X protocol).
Unless there's a program specific to your environment that is causing this, I would say that this is partially fixable. There's some kind of bug/weird implementation detail in the macOS vsync driver that causes massive lag in XQuartz.app and macports' X11.app.
https://www.youtube.com/watch?v=IaPh4tc0_B0
If you use XQuartz regularly, I would highly recommend you install Quartz Debug.app so you can disable vsync before you hop into X.
https://download.developer.apple.com/Developer_Tools/Additio...
Unless there's a program specific to your environment that is causing this, I would say that this is partially fixable. There's some kind of bug/weird implementation detail in the macOS vsync driver that causes massive lag in XQuartz.app and macports' X11.app.
https://www.youtube.com/watch?v=IaPh4tc0_B0
If you use XQuartz regularly, I would highly recommend you install Quartz Debug.app so you can disable vsync before you hop into X.
https://download.developer.apple.com/Developer_Tools/Additio...
>The previous release was in 2016, so I was sure that XQuartz was dead for good.
Why though? It's not like the XWindows protocol changes that much (or at all).
Having to do a new release for a new architecture like Apple Sillicon, sure, but that's another thing.
Why though? It's not like the XWindows protocol changes that much (or at all).
Having to do a new release for a new architecture like Apple Sillicon, sure, but that's another thing.
Not sure how XQuartz works, but Apple does like to deprecate APIs when a new one comes out. So if XQuartz relied on any deprecated ones, that would be an issue when they get removed.
hm, I'm using X11 forwarding when I'm on my mac box to control my music player and there is pretty much no latency (and text isn't a blurry mess like rdp / vnc but crisp and sharp). I'm on a gigabit network though.
X11 was designed at a time when local networks carried only a few megabits per second. But apps back then didn't depend on sending lots of bitmaps over the wire, just mostly drawing primitives.
Depends on the program! - I've never minded using Emacs that way, even just over wifi, but a lot of more modern stuff is basically unusable. (I assume these programs draw everything to a local buffer, and then copy that to the screen. Probably fine locally, and I'm sure you do get more control, but it's a lot of data to go over a network!)
in my case it's Strawberry which is a modern Qt 5 app. I also tried retroarch that way and it works surprisingly well.
Local network of VPN? My first attempt at running IntelliJ across VPN last year was using XQuartz and it worked, but latency was terrible and when changing connectivity it would die. Using VNC allowed the process to keep running in the server session over periods of weeks.
Indeed, I was amazed when I installed it today and it popped up the Beta update dialog when I launched it. Happy to see it's not abandoned.
> Older builds required either a lot of hand-holding or Apple
Internal tools, so this will hopefully be a step towards making it easier for
others to drive future releases of XQuartz. If that is something you'd be
interested in, please let me know.
Sounds like they are planning on having the community take over responsibility for XQuartz. Nonetheless it’s great that they put in the work of bringing native Apple Silicon support and making a build system for it that others can use.
Anyways I personally much more rarely need XQuartz now than before, but it’s good to have it be available still if and when you need it.
Sounds like they are planning on having the community take over responsibility for XQuartz. Nonetheless it’s great that they put in the work of bringing native Apple Silicon support and making a build system for it that others can use.
Anyways I personally much more rarely need XQuartz now than before, but it’s good to have it be available still if and when you need it.
> Sounds like they are planning on having the community take over responsibility for XQuartz.
Either that, or they realised that it would be literally impossible to build it on Apple Silicon, if the hand holding became not possible and the internal tools not available.
Either that, or they realised that it would be literally impossible to build it on Apple Silicon, if the hand holding became not possible and the internal tools not available.
The community took over responsibility for XQuartz almost a decade ago. The build / release process that relied on some internal tooling, which meant only I could do it (until I finally spent a couple days writing a new release script over the Winter holiday).
> Sounds like they are planning on having the community take over responsibility for XQuartz.
I think that was their plan for most open source software, but xquartz is more critical than most.
I think that was their plan for most open source software, but xquartz is more critical than most.
Awesome. Something about this post really hits home about the amazing people working quietly behind the scenes chipping away to keep everything running.
And then Tom Lane is the first person to weigh in to give thanks?! How do these people manage the breadth of contribution that they do?
And then Tom Lane is the first person to weigh in to give thanks?! How do these people manage the breadth of contribution that they do?
A surprising number of features exist in OSX to make it comfortable for people used to Unix-like OSes. It's a shame Apple is so poorly behaved, I'd think about buying a personal mac if it weren't for that.
Their terminal app will simulate a selection buffer for you (although it doesn't integrate with other apps which is why I end up pasting garbage into my terminal almost every time I clone something from github) and can optionally simulate pointer style focus like many X11 window managers do.
Every text widget in Cocoa seems to use Emacs-style GNU readline shortcuts. Something I didn't notice until recently.
Xquartz isn't dead, and interestingly Xlib has outlasted quickdraw and carbon, their own drawing APIs.
Their terminal app will simulate a selection buffer for you (although it doesn't integrate with other apps which is why I end up pasting garbage into my terminal almost every time I clone something from github) and can optionally simulate pointer style focus like many X11 window managers do.
Every text widget in Cocoa seems to use Emacs-style GNU readline shortcuts. Something I didn't notice until recently.
Xquartz isn't dead, and interestingly Xlib has outlasted quickdraw and carbon, their own drawing APIs.
quickdraw and carbon were explicitly presented as legacy APIs when OSX was introduced and were supported for backwards compatibility reasons.
Quartz on the other hand, the actual supported API, has over time outclassed Xlib in almost every conceivable way.
Quartz on the other hand, the actual supported API, has over time outclassed Xlib in almost every conceivable way.
Quartz does outclass Xlib in every way except portability and the shear number of language bindings.
There are clearly a couple of people who really care about this internally and push to let it keep these features. I hope that the day when they are drowned out by the rest of the company does not come…
Question: running GTK apps in a Linux VM under Parallels in “coherence mode” provides a better user-experience (in several ways: smoother, better accessibility, etc.) than running a native-macOS-compiled GTK apps under XQuartz does. Why is this?
• Is it a difference of display model? Where/when compositing is done? Is X11 really that high-overhead of a protocol, that putting a “compositor in your compositor” like Parallels’ video driver does, can do better?
• Is it that macOS GTK apps are relying on macOS as the window manager / window decorator (which those apps were never heavily tested for), while “coherence mode” GTK apps are bringing their own DE (GNOME or what-have-you) along with them onto the macOS desktop, which “knows” what to do with those apps much better?
• Something else I’m not thinking of?
• Is it a difference of display model? Where/when compositing is done? Is X11 really that high-overhead of a protocol, that putting a “compositor in your compositor” like Parallels’ video driver does, can do better?
• Is it that macOS GTK apps are relying on macOS as the window manager / window decorator (which those apps were never heavily tested for), while “coherence mode” GTK apps are bringing their own DE (GNOME or what-have-you) along with them onto the macOS desktop, which “knows” what to do with those apps much better?
• Something else I’m not thinking of?
I wouldn't discount the extent to which a Linux distro might tweak some config files and optional dependencies.
An example: when I started using freebsd on a laptop the fonts were pretty crappy relative to Linux. The code for Xorg, freetype etc. were identical in both places. I spent some time editing config files and it looked decent again. I assume my debian setup just had better defaults.
An example: when I started using freebsd on a laptop the fonts were pretty crappy relative to Linux. The code for Xorg, freetype etc. were identical in both places. I spent some time editing config files and it looked decent again. I assume my debian setup just had better defaults.
It's always worked on M1 when compiled from MacPorts... I don't understand what has changed.
The xorg-server port provided by MacPorts had already been a newer version than the previous official XQuartz release (from 2016) for a while.
It probably used the Rosetta emulation layer before
Compiled from MacPorts, so source for AS...
Correct, I've been recommending folks use MacPorts to build xorg-server if they want to stay up to date as I was not able to put out new XQuartz releases for a while. Right now, there are a few bug fixes in the latest XQuartz release which I haven't pulled back into MacPorts yet, but I'll do that at some point soon.
This is a binary package built for ARM to. E installed directly without other dependencies. Macports builds from source
Is it related to Quartz composer?
It's an X11 implementation that runs on Mac OS, so it does indeed run X11 over the top of the Quartz graphics system that Mac OS uses.
From very far.
Quartz Composer is a graph of filers that you can interconnect in a graphical interface. You use it to create visual filters or generators. iTunes was using Quartz composer files .qtz for some of his music visualizers.
Quartz Composer is GPU accelerated thanks to its use of the Quartz API.
It was very popular with artists because of the creative freedom it gave when composing the filters. You did not need to be a developer to create a filter, thanks to the editing application.
Quartz Composer is now deprecated and dying in slow and anonymous death.
XQuartz is a windowing system accelerated with Quartz. The X system was not invented by Apple but very popular on top of Unix.
Quartz Composer is a graph of filers that you can interconnect in a graphical interface. You use it to create visual filters or generators. iTunes was using Quartz composer files .qtz for some of his music visualizers.
Quartz Composer is GPU accelerated thanks to its use of the Quartz API.
It was very popular with artists because of the creative freedom it gave when composing the filters. You did not need to be a developer to create a filter, thanks to the editing application.
Quartz Composer is now deprecated and dying in slow and anonymous death.
XQuartz is a windowing system accelerated with Quartz. The X system was not invented by Apple but very popular on top of Unix.
quartz composer is completely different.
xquartz does the X11 protocol and displays it on apple display.
quartz composer is a sort of graphical composition tool.
They just happen to have quartz 2d graphics api in common.
xquartz does the X11 protocol and displays it on apple display.
quartz composer is a sort of graphical composition tool.
They just happen to have quartz 2d graphics api in common.
Kind of - they're both from the same era when Quartz was the branding for any graphics things.
I wonder why they dropped support for cairo?
There was some trouble getting a release out the door some time back, due to lack of maintainers available to do it apparently:
https://news.ycombinator.com/item?id=25076197
Though they did manage in the end - latest one was Nov. 2020 - the person who did it said it would be his last https://www.cairographics.org/news
Though they did manage in the end - latest one was Nov. 2020 - the person who did it said it would be his last https://www.cairographics.org/news
Does this mean it's no longer officially supported?
I occasionally use XQuartz to run graphical programs over SSH using X forwarding, although I’ve mostly moved on to other approaches due to a combination of:
1. Bad support for HiDPI displays (theoretically fixable in XQuartz - curious if they will tackle it now).
2. Annoyingly high input and redisplay latency (probably not fixable, just an inherent property of the very chatty X protocol).
Still nice to have the option.