Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
431 lines (217 sloc) 22.2 KB
original_url created_at updated_at closed_at status type resolution reporter owner priority milestone component version cc
2012-10-08 07:12:22 -0700
2015-11-02 08:55:00 -0800
2015-11-02 08:55:00 -0800
closed
usability
Duplicate
mail.pourri@…
jeremyhu@…
Important
later
xserver
2.7.4 (xserver-1.13.0)
marspeoplester@…
anton@…
rfabbri@…
razzfazz@…
macports@…

XQuartz does not support retina displays well

Run XQuartz 2.7.4, and trigger xfontsel, select any font, they all looks ugly. In all X11 applications, fonts are blurry or ugly (just check the title on any X11 window).

This might be due to the retina display on MacBookPro, but I would expect the font renderer in XQuartz to be aware of the screen resolution at least for text rendering.


jeremyhu@… commented on Oct 8, 2012

  • Status changed from new to assigned
  • Summary changed from XQuartz font rendering looks bad on mountain lion to XQuartz does not support retina displays well
  • Milestone set to later

Yes, it's because of the scaling for your retina display. Essentially every X11 pixel is rendered to 4 real pixels. This is a common problem not unique to X11.


macosforge@… commented on Dec 4, 2012

Oh please, add this!

No linux distribution properly supports the retina display yet, and running them inside virtual machines is not so pleasant. But if X11 adds this support, it will be possible to forward the linux applications inside the virtual machine through ssh, allowing us to run them as if they were native OS X programs with full font resolution! X11 would be running on my computer 24/7 alongside parallels! Are you looking into this currently or are you working on other priorities for X11? If you are too busy to deal with this feature, I could try to look into the font code and help.

Thank you.


macosforge@… commented on Dec 5, 2012

Oh damn. I realise now that the font rendering is done client side. So I guess it's not possible to have windows displaying low-res bitmaps, with fonts being displayed in hi-res as I was dreaming of. XRender would need to render the windows in scaled 1440x900, and Xft would need to deal with the fonts in 2880x1800... but Xft uses XRender... it seems a lot of hacking would be necessary to achieve this, if possible at all. And simply making X11 retina aware will make the windows tiny, just like in the virtual machine. =(


jeremyhu@… commented on Dec 5, 2012

yep ... highly nontrivial ... =(


eric-macosforge@… commented on Dec 5, 2012

Why is it so difficult to do this? What does OS X do that makes it difficult to get at the full resolution of the display?


jeremyhu@… commented on Dec 5, 2012

You can easily get the full resolution of the display. That functionality has always been there since I added RandR support.

The problem is that your windows will appear half the physical size.


jeremyhu@… commented on Dec 5, 2012

X11 just doesn't work well for resolutions outside of the 72-90 DPI range. This is an upstream X11 issue that needs to be solved before we can really do anything about it in XQuartz.


eric-macosforge@… commented on Dec 5, 2012

Replying to jeremyhu@…:

You can easily get the full resolution of the display. That functionality has always been there since I added RandR support.

The problem is that your windows will appear half the physical size.

Well, that sounds like a stupid application issue. They should be asking for point sizes instead of pixel sizes for fonts and scaling things to the physical dimensions of the screen.

I'm willing to try to ride herd over stupid applications and misconfigure them so they act correctly on hi-res displays. Sounds like I need to find an X app that gives me a fairly direct way to manipulate RandR.


eric-macosforge@… commented on Dec 5, 2012

Except using xrandr to set the resolution results in X11 going into fullscreen mode, and I don't know how to get it out. *laugh* Oops!


eric-macosforge@… commented on Dec 5, 2012

If it were somehow possible to enter 2880x1800 mode without having XQuartz go into fullscreen mode, that would be perfect for me. I tested, and if I just configure things to use enormous (well, they would be if they were actually scaled correctly) fonts, they end up looking beautiful. I could stop using Terminus and start using a decent anti-aliased font for my emacs and terminal windows.


jeremyhu@… commented on Dec 5, 2012

Replying to eric-macosforge@…:

Replying to jeremyhu@…:

You can easily get the full resolution of the display. That functionality has always been there since I added RandR support.

The problem is that your windows will appear half the physical size.

Well, that sounds like a stupid application issue. They should be asking for point sizes instead of pixel sizes for fonts and scaling things to the physical dimensions of the screen.

Who is "they"? X11 predates OS X by over a decade and is heavily focused on pixels. What goes to those pixels is the X11 client's responsibility. This is the underlying problem. An X11 client can use points, but then that is sent to the server in a pixmap, and that pixmap is then upscaled to 2x and rendered inside of a window. =/

I'm willing to try to ride herd over stupid applications and misconfigure them so they act correctly on hi-res displays. Sounds like I need to find an X app that gives me a fairly direct way to manipulate RandR.

You've got one. It's called 'xrandr' ;)

Replying to eric-macosforge@…:

Except using xrandr to set the resolution results in X11 going into fullscreen mode, and I don't know how to get it out. *laugh* Oops!

cmd-opt-a

Replying to eric-macosforge@…:

If it were somehow possible to enter 2880x1800 mode without having XQuartz go into fullscreen mode, that would be perfect for me. I tested, and if I just configure things to use enormous (well, they would be if they were actually scaled correctly) fonts, they end up looking beautiful. I could stop using Terminus and start using a decent anti-aliased font for my emacs and terminal windows.

I agree. That would be a good solution. I suggest you take a look at the "fake" resolutions that are added to RandR (in quartzrandr.c I think) for the rootless mode and add new rootless one for the desired resolution ... another option is to just start X11 while in that resolution.


eric-macosforge@… commented on Dec 6, 2012

Replying to jeremyhu@…:

Who is "they"? X11 predates OS X by over a decade and is heavily focused on pixels. What goes to those pixels is the X11 client's responsibility. This is the underlying problem. An X11 client can use points, but then that is sent to the server in a pixmap, and that pixmap is then upscaled to 2x and rendered inside of a window. =/

*nod* Yeah. I've not written many GUI programs, but when I do I always try to specify things in terms of a coordinate system that's resolution independent. It's one of those basic things like making sure you don't count on your integers being little or big endian. Those clean habits. X has this nice thing that allows you to ask the physical size of the display. I used to set that in my Xorg.conf file by using a ruler to measure my screen in the hopes someone paid attention. :-)

You've got one. It's called 'xrandr' ;)

Yep. :-) I figured that one out. ;-)

cmd-opt-a

Figured that out too. I was way too chatty on this bug. :-)

I agree. That would be a good solution. I suggest you take a look at the "fake" resolutions that are added to RandR (in quartzrandr.c I think) for the rootless mode and add new rootless one for the desired resolution ... another option is to just start X11 while in that resolution.

The last, I'm not sure I understand you. I thought I had started X11 while in that resolution. But, it looks like Apple plays a lot of interesting games in this department in order to account for stupid apps, so it's really hard to tell.


jeremyhu@… commented on Dec 6, 2012

Replying to eric-macosforge@…:

Replying to jeremyhu@…:

Who is "they"? X11 predates OS X by over a decade and is heavily focused on pixels. What goes to those pixels is the X11 client's responsibility. This is the underlying problem. An X11 client can use points, but then that is sent to the server in a pixmap, and that pixmap is then upscaled to 2x and rendered inside of a window. =/

*nod* Yeah. I've not written many GUI programs, but when I do I always try to specify things in terms of a coordinate system that's resolution independent. It's one of those basic things like making sure you don't count on your integers being little or big endian. Those clean habits. X has this nice thing that allows you to ask the physical size of the display. I used to set that in my Xorg.conf file by using a ruler to measure my screen in the hopes someone paid attention. :-)

Yeah, there was an attempt to fix this problem using that information, but there were multiple issues in adoption. That information isn't really used. That being said, with all the higher and higher resolution options out there, X11 will really *need* to address this sooner than later, and we can probably piggy-back on that effort.

I agree. That would be a good solution. I suggest you take a look at the "fake" resolutions that are added to RandR (in quartzrandr.c I think) for the rootless mode and add new rootless one for the desired resolution ... another option is to just start X11 while in that resolution.

The last, I'm not sure I understand you. I thought I had started X11 while in that resolution. But, it looks like Apple plays a lot of interesting games in this department in order to account for stupid apps, so it's really hard to tell.

Yeah, let me explain. Let's say you have a 1440x900 "retina" display. That display is really 2880x1800 pixels. Now there should be three different modes that may be confused with eachother:

2880x1800 - Things will be really small ... the menubar will be 22 real pixels tall ... I think this is what you want.

1440x900 "retina" - It's really 2880x1800, but some things based on pixel size believe they are 1440x900, so the menubar which is 22 "pixels" is really 44 pixels tall.

1440x900 - This resolution will truely be 1440x900 internally and upscaled to 2880x1800 by the display. The menubar will be 22 pixels in the framebuffer and upscaled to 44 pixels on the display.


eric-macosforge@… commented on Dec 9, 2012

Replying to jeremyhu@…:

Replying to eric-macosforge@…:

The last, I'm not sure I understand you. I thought I had started X11 while in that resolution. But, it looks like Apple plays a lot of interesting games in this department in order to account for stupid apps, so it's really hard to tell.

Yeah, let me explain. Let's say you have a 1440x900 "retina" display. That display is really 2880x1800 pixels. Now there should be three different modes that may be confused with eachother:

2880x1800 - Things will be really small ... the menubar will be 22 real pixels tall ... I think this is what you want.

No, I was hoping for peaceful coexistence with native OS X apps. It's not all that easy to misconfigure OS X to have appropriately wrong font-sizes for a really hi-res screen. It's relatively easy to misconfigure GNOME to do this as all the font-sizes used for various UI elements are actually available in a configuration dialog.

And emacs of course, with emacs you can configure everything to your heart's content.

1440x900 "retina" - It's really 2880x1800, but some things based on pixel size believe they are 1440x900, so the menubar which is 22 "pixels" is really 44 pixels tall.

This, I think, is the mode I would like to run in and have X be one of the programs that's fully aware of the true 2880x1800 nature of the display.

1440x900 - This resolution will truely be 1440x900 internally and upscaled to 2880x1800 by the display. The menubar will be 22 pixels in the framebuffer and upscaled to 44 pixels on the display.

Or maybe those mode. But I suspect not. I notice, for example, that all of the letters displayed by OS X apps currently are incredibly smooth. 2880x1800 smooth. I don't think that would happen in this mode.

Of course, several games that run in fullscreen at '1440x900' probably use this mode.


eric-macosforge@… commented on Dec 10, 2012

Replying to jeremyhu@…:

I agree. That would be a good solution. I suggest you take a look at the "fake" resolutions that are added to RandR (in quartzrandr.c I think) for the rootless mode and add new rootless one for the desired resolution ... another option is to just start X11 while in that resolution.

I just tried to get a nice git checkout to compile in the hopes of finding what you're talking about and messing with it. So many dependencies above and beyond Xcode tools and command line utilities. I don't think I can get a development environment that works. *frown*


jeremyhu@… commented on Dec 10, 2012

You just need to install XCode's command line tools, autoconf, automake, glibtool, and pkg-config.


macosforge@… commented on Dec 10, 2012

Currently, the virtual machine Parallels 8 has an option to export retina resolution (2880x1800) to the linux guest even when running on 1440x900 HiDPI on the host. This way, the OSX programs stay "normal size" because they see the desktop as 1440x900, but the linux programs become tiny because Parallels tells them the desktop is 2880x1800.

Wouldn't it be possible to implement the same thing in X11 as a temporary solution? X11 would export to the clients that the desktop resolution is 2880x1800, and although the X11 windows would be really small, we would be able to configure the fonts to be "huge" so they look normal. This is already possible with xrandr, but only in fullscreen mode with a root window, not in rootless mode.


eric-macosforge@… commented on Dec 11, 2012

Replying to jeremyhu@…:

You just need to install XCode's command line tools, autoconf, automake, glibtool, and pkg-config.

This risks going outside the scope of this bug, but...

$ brew install libtool
Error: libtool-2.4.2 already installed
$ brew install pkg-config
Error: pkg-config-0.27.1 already installed
$ brew install autoconf
Error: autoconf-2.69 already installed
$ brew install automake
Error: automake-1.12.5 already installed
$ sh autogen.sh 
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
configure.ac:51: error: must install fontutil 1.1 or later before running autoconf/autogen
configure.ac:51: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: /usr/local/Cellar/autoconf/2.69/bin/autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

jeremyhu@… commented on Dec 11, 2012

You need to setup your environment. See the link on the left for Developer Info. You need to setup the ACLOCAL and PKG_CONFIG_PATH environment variables.


jeremyhu@… commented on Dec 11, 2012

And if there is something unclear (or wrong) in that wiki page, please let me know rather than throwing in the towel. I want to make sure that page is accurate and easy to follow to allow people like you to poke around without much difficulty.


macosforge@… commented on Dec 11, 2012

I have one complaint! In the Developer Info wiki page you can read:

"For simple, verified, step-by-step instructions for building and installing XQuartz, see the Build Instructions page. They can be a good starting place for setting up your development environment"

But the Build Instructions page has no instructions at all. The real instructions are in the Developer Info page itself, scrolling down. This confused me a lot the first time I tried to build XQuartz.

BTW, I think we should open a new ticket for this subject. It will dilute the original bug report.


wangzhenj321@… commented on Oct 17, 2013

Could do help me figure out this problem? If it is possible, please email me.


marspeoplester@… commented on May 16, 2014

  • Cc marspeoplester@… added

anton@… commented on May 29, 2014

  • Cc anton@… added

rfabbri@… commented on Sep 15, 2014

  • Cc rfabbri@… added

razzfazz@… commented on Oct 21, 2014

  • Cc razzfazz@… added

macports@… commented on May 12, 2015

  • Cc macports@… added

macports@… commented on May 12, 2015

My use case is super niche, so feel free to ignore me, but I'd be fine with a mode that just surfaces the full physical resolution of the device's screen and turning up the font sizes on my terminal and text editor windows.


macports@… commented on Sep 8, 2015

because of this issue, i migrated everything i was using under xquartz to run under a virtualbox ubuntu vm instead, and was surprised at how many applications gracefully handle it when you set Xft.dpi in .Xresources to something higher than 192. most remain usable, and many, like firefox, are perfect. i really don't think it's fair to say this is an upstream X11 bug, when many application developers have already done everything that is required to handle this kind of display. a virtualbox-esque option to expose the full resolution of the display is an adequate solution, and people running stuff under X on OS X are probably generally well-equipped to handle the weirdness that might fall out of it.


jeremyhu@… commented on Oct 23, 2015

Mass Edit

As you may have noticed, we have had issues with spam in trac for the past couple years. We've decided to migrate to using freedesktop.org's bugzilla for our bug tracker (more details will be coming on the mailing lists in the next couple weeks).

I don't want us to loose valuable bug reports in the transition, so I want to make sure that any relevant open issues in this MacOSForge trac are migrated over to the new system. If you are interested in this issue, please take a few minutes to file a new bug for this issue in bugzilla. Please make sure to do the following:

  • Copy over all relevant information into that report, just in case we loose this one.
  • Set the URL field of the bugzilla report to this trac ticket's URL.
  • Paste the URL of the new bugzilla report as a comment in this ticket, and I'll close it out.

jeremyhu@… commented on Nov 2, 2015

  • Status changed from assigned to closed
  • Resolution set to Duplicate

https://bugs.freedesktop.org/show_bug.cgi?id=92777

You can’t perform that action at this time.