• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: X.org / X11.app source code distribution available; cursor fix binary, too
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: X.org / X11.app source code distribution available; cursor fix binary, too


  • Subject: Re: X.org / X11.app source code distribution available; cursor fix binary, too
  • From: Ben Byer <email@hidden>
  • Date: Wed, 31 Oct 2007 14:05:22 -0700


On Oct 31, 2007, at 8:41 AM, Aaron Bannert wrote:


On Oct 30, 2007, at 7:27 PM, Ben Byer wrote:

I was able to successfully build and run Xquartz using your above instructions and your tarball. Can't do -arch x86_64 yet though (fails while building crAppleWM.m -> crAppleWM.o).

Yeah; we have not made any effort to build Xquartz as 64-bit because it doesn't seem like there's much benefit to do so -- X11 client apps, sure, but a 64-bit client can talk to a 32-bit server.

I can think of one big benefit, and possibly another:

1) x86_64 has twice as many general registers.

2) Darwin's VM avoids mapping x86_64 pages into the same virtual address range as the kernel (which is allowed on 32-bit archs under Darwin, basically a tradeoff in performance so Photoshop can allocate all 4GB of mem). This basically means that x86_64 has potentially much cheaper context switches, which is something I'm guessing X11 does a *lot* of, so that could be a big win for interactivity across the whole system. I could be wrong about the nitty gritty details of Darwin's VM, but it's definitely worth testing out.

So it may not be top priority now given feature bugs, but after those are handled we'll probably see a nice bump in speed when we go to 64-bit X11.


Fair enough -- right now, if it were the only 64-bit process, we'd pay a memory consumption hit by loading 64-bit frameworks which would not otherwise be necessary. Eventually, that will cease to be an issue (if more things run as 64-bit binaries).

If you want to try playing with it, just nuke crAppleWM -- it's only needed if you don't have libXplugin, and it's superceded by xprAppleWm.
--
Ben Byer
CoreOS / BSD Technology Group, XDarwin maintainer


_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list      (email@hidden)
This email sent to email@hidden


References: 
 >X.org / X11.app source code distribution available; cursor fix binary, too (From: Ben Byer <email@hidden>)
 >Re: X.org / X11.app source code distribution available; cursor fix binary, too (From: Aaron Bannert <email@hidden>)
 >Re: X.org / X11.app source code distribution available; cursor fix binary, too (From: Ben Byer <email@hidden>)
 >Re: X.org / X11.app source code distribution available; cursor fix binary, too (From: Aaron Bannert <email@hidden>)

  • Prev by Date: Re: X11 Leopard Fails to Start
  • Next by Date: Re: Tiger X11 on Leopard
  • Previous by thread: Re: X.org / X11.app source code distribution available; cursor fix binary, too
  • Next by thread: Re: cursor fix binary
  • Index(es):
    • Date
    • Thread