[HN Gopher] New Xquartz release with native Apple Silicon support
___________________________________________________________________
New Xquartz release with native Apple Silicon support
Author : ismiseted
Score : 207 points
Date : 2021-01-30 08:50 UTC (14 hours ago)
(HTM) web link (www.mail-archive.com)
(TXT) w3m dump (www.mail-archive.com)
| mastrsushi wrote:
| Does this mean it's no longer officially supported?
| asperous wrote:
| There's no official commitment to support it but if an Apple
| Engineering Manager is spending a month updating it I would
| guess they want to keep it alive for now.
| zymhan wrote:
| Xquartz's website has stated it is not officially supported
| forever.
| derefr wrote:
| 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?
| asveikau wrote:
| 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.
| codetrotter wrote:
| > 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.
| m463 wrote:
| > 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.
| azalemeth wrote:
| > 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.
| alexhutcheson wrote:
| Wow. The previous release was in 2016, so I was sure that XQuartz
| was dead for good. Nice to be pleasantly surprised!
|
| 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.
| jd3 wrote:
| > 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...
| jcelerier wrote:
| 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.
| tom_ wrote:
| 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!)
| jcelerier wrote:
| in my case it's Strawberry which is a modern Qt 5 app. I
| also tried retroarch that way and it works surprisingly
| well.
| cbm-vic-20 wrote:
| 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.
| mleo wrote:
| 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.
| zymhan wrote:
| 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.
| coldtea wrote:
| > _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.
| m463 wrote:
| Weird, on a 10.11 system - no mountable filesystems.
|
| opens fine on 10.15 - identical md5
| saagarjha wrote:
| Perhaps some sort of APFS thing?
| Infiltrator wrote:
| It's always worked on M1 when compiled from MacPorts... I don't
| understand what has changed.
| raimue wrote:
| The xorg-server port provided by MacPorts had already been a
| newer version than the previous official XQuartz release (from
| 2016) for a while.
| asperous wrote:
| It probably used the Rosetta emulation layer before
| coldtea wrote:
| Compiled from MacPorts, so source for AS...
| pilif wrote:
| This is a binary package built for ARM to. E installed directly
| without other dependencies. Macports builds from source
| swiley wrote:
| 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.
| zepto wrote:
| 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.
| Jkvngt wrote:
| But I thought X was dead? Every day or two I read about how X is
| dead here, on Slashdot, Twitter, on Michael Larabel's site,
| everybody chanting it in unison. How could all these voices be
| wrong? X11 is _ALIVE?_
| aidos wrote:
| 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?
| Lucasoato wrote:
| Is it related to Quartz composer?
| m463 wrote:
| 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.
| fredoralive wrote:
| 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.
| FraKtus wrote:
| 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.
| mkj wrote:
| Kind of - they're both from the same era when Quartz was the
| branding for any graphics things.
| enjoy-your-stay wrote:
| I wonder why they dropped support for cairo?
___________________________________________________________________
(page generated 2021-01-30 23:01 UTC)