> On Oct 12, 2016, at 02:40, René J.V. Bertin <rjvber...@gmail.com> wrote:
> On Wednesday October 12 2016 02:08:36 Jeremy Huddleston Sequoia wrote:
>>> Technically debatable (if you ask for pixels you shouldn't be earning any 
>>> points ;))
>> Nothing asks for pixels.  This code existed long before the difference 
>> existed (or rather before API existed to distinguish the difference) and has 
>> just never been updated.
> OK, I guess that's the other sensible explanation; I just didn't think of it 
> (somewhere I still remember my first peeks and pokes ;) )
>> Not necessarily.  It is in practice, but there's no guarantee that it will 
>> always be the case.
> I have no idea what points are, but I have a problem with the idea of turning 
> on or off the umptieth of a pixel :)
>>> So what happens when you use a regular (say 1080p) external in combination 
>>> with a Retina display, and for good measure you deactivate "screens have 
>>> separate spaces" to get the traditional 
>>> spaces-span-all-screens-of-the-desktop behaviour?
>> You'd have one 1920x180 display at 1x and another display at 2x.  As you 
>> drag (non X11) windows between them, they'll adjust their scale factors.
> I trust Apple to make that work even if you leave the window spanning 
> multiple screens, but the question was about XQuartz. Sorry I didn't mention 
> that explicitly.

The NSWindow case is what we really want to emulate.  In that case, whichever 
display has "more" of the window determines the scale factor of the window 
(meaning 1x/2x and 2x/1x scale mismatching, possible scale artifacts, etc).

X11 doesn't handle these cases at all very well, and that's one of the reasons 
why XtoQ based on libxcwm is really the right direction to go for the future of 
XQuartz... if anyone wants to put in the effort to pick that effort up, it 
would be a great project to finish.

>> Yes, but the issue existed before retina.  It just got quite a bit more 
>> obviously challenging with such a larger range of dot pitch available.  Ten 
>> years ago, most displays were around ~100 dpi.  Now we've got displays above 
>> 400.
> True, and the value obtained from the hardware was rarely reliable either (in 
> my experience at least).

Unreliable EDID?!?  No way!  That's unheard of.  I'm shocked...

Yeah... all ... too ... common ...

>> RandR doesn't really have anything to do with modelines.  And thanks for 
>> that shuttering and horrific set of memories that you just conjured up by 
>> just mentioning modelines...
> LOL, you're welcome and goodmorning :) I don't know about XQuartz, but I've 
> had to figure out the modelines issue when adding new modes to the list on my 
> Linux systems (xrandr  --newmode "1366x768" 85.25 1366 1440 1576 1784 768 771 
> 781 798 -hsync +vsync). 
>> You can use xrandr from the command line to put XQuartz into fullscreen mode 
>> at the native display pixel resolution (eg: `xrandr -s 2880x1800`), 
> That's probably a good enough workaround for the OP for now. 
>> but that will be a fullscreen mode and will render your windows much smaller 
>> than what you want.
> How so? If you want 100x100 px and you get 100x100px you got what you asked 
> for ;)

Ok, well I guess you'll get what you want, for some interpretation of that.

> Afterwards you just have to change your configuration, starting with Xft.dpi, 
> and the window sizes you request. Not a problem as far as I can see, as long 
> as you don't try to use those same settings on a regular display (and you 
> don't depend on bitmap fonts only available for lower resolutions) ...

It's a rabbit hole, but indeed it's software and configuration options and 
should be solvable ... especially with a rather simple WM like twm.  Various 
apps might not behave well, but perhaps over the past few years, they've been 
getting better about being on high dpi displays.

> Mostly unrelated: do you happen to know if anyone has considered or discussed 
> bringing Wayland to the Mac?

I've thought about it.  It would certainly mesh a lot better with macOS than 
X11 does, but AFAIK, nobody has mentioned working on it.  I'd expect a 
discussion in xquartz-dev at least mentioning the project if they were.


> R
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> X11-users mailing list      (X11-users@lists.apple.com)
> Help/Unsubscribe/Update your Subscription: 
> https://lists.apple.com/mailman/options/x11-users/jeremyhu%40freedesktop.org
> This email sent to jerem...@freedesktop.org

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Do not post admin requests to the list. They will be ignored.
X11-users mailing list      (X11-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription: 

This email sent to arch...@mail-archive.com

Reply via email to