plan9port on Apple high-DPI displays

[Russ Cox]

I just committed a bunch of changes that turn on 'devdrawretina' mode by default, so that plan9port programs draw actual screen pixels instead of virtual pixels that OS X resamples. By default, the effect should be clearer displays but nothing terribly obvious changed. Behind the scenes, libdraw is pixel-doubling all the bitmap fonts when running on ≥200 DPI displays, so that they remain legible.

Fontsrv(4) can be used to refer to system-installed fonts instead. Those fonts are now OS X font fallback-aware, meaning that you get Japanese characters instead of Peter faces.

Finally, libdraw supports moving a window from a low-DPI to a high-DPI screen. Display.dpi changes, as do the font metrics for all open fonts. The default is to double the font size, either by pixel doubling a bitmap font or scaling a fontsrv font. For more control, the argument to openfont(3) and therefore $font and the various -f and -F program arguments can be a comma-separated pair of fonts, one for low-DPI and one for high-DPI.

Today, I am using:

    font=/usr/local/plan9/font/lucm/unicode.9.font,/mnt/font/Menlo-Regular/25a/font

and

    acme -f /lib/font/bit/lucsans/euro.8.font,/mnt/font/LucidaGrande/25a/font \

       -F /usr/local/plan9/font/pelm/unicode.9.font,/mnt/font/Menlo-Regular/25a/font

Rob is using LucidaGrande at 30a for high-DPI.

See font(7) (9 man 7 font) for details about font syntax.

Russ

[marius eriksen]

This works great, thanks!

I'm looking forward to not having to kill my acme session several times each day. 

-m.

--

---
You received this message because you are subscribed to the Google Groups "plan9port-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plan9port-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jordi Bunster]

I had already given up on proportional fonts so I could use -f and -F
as two sizes of the same monospaced font. Maybe now I can try to go
back, although the bigger font came in handy during presentations.

[Jens Frederich]

Hello Russ, nice work.

But fontsrv build fails on Linux:

st% mk

9c -I/usr/include -I/usr/include/freetype2 x11.c

x11.c:107:9: error: ‘xf’ redeclared as different kind of symbol

  XFont *xf, *xfp, *xfe;

         ^

x11.c:105:18: note: previous definition of ‘xf’ was here

 mksubfont(XFont *xf, char *name, int lo, int hi, int size, int antialias)

                  ^

x11.c:107:20: warning: unused variable ‘xfe’ [-Wunused-variable]

  XFont *xf, *xfp, *xfe;

                    ^

x11.c:107:14: warning: unused variable ‘xfp’ [-Wunused-variable]

  XFont *xf, *xfp, *xfe;

              ^

mk: 9c -I/usr/include -I/usr/include/freetype2 x11.c  : exit status=exit(1)

Why is fontsrv not built automatically?

[Russ Cox]

On Wed, Feb 18, 2015 at 6:25 AM, Jens Frederich <jfred...@gmail.com> wrote:

Hello Russ, nice work.

But fontsrv build fails on Linux:

Fixed (I hope), thanks.

 

Why is fontsrv not built automatically?

Because it requires libfreetype, and I don't want to force that requirement on all users of plan9port.

Russ

[Jens Frederich]

On Wed, Feb 18, 2015 at 3:47 PM, Russ Cox <r...@swtch.com> wrote:

On Wed, Feb 18, 2015 at 6:25 AM, Jens Frederich <jfred...@gmail.com> wrote:

Hello Russ, nice work.

But fontsrv build fails on Linux:

Fixed (I hope), thanks.

 

Thanks it works.
 

Why is fontsrv not built automatically?

Because it requires libfreetype, and I don't want to force that requirement on all users of plan9port.

Okay, this makes sence.

Jens

[Jens Frederich]

On Tue, Feb 17, 2015 at 9:59 PM, Russ Cox <r...@swtch.com> wrote:

Today, I am using:

    font=/usr/local/plan9/font/lucm/unicode.9.font,/mnt/font/Menlo-Regular/25a/font

and

    acme -f /lib/font/bit/lucsans/euro.8.font,/mnt/font/LucidaGrande/25a/font \

       -F /usr/local/plan9/font/pelm/unicode.9.font,/mnt/font/Menlo-Regular/25a/font

Rob is using LucidaGrande at 30a for high-DPI.

 

25a and 30a font size? This is big. Do you use a 5k iMac? I'm using a Chromebook Pixel with 14a.

Jens

[Jesper Louis Andersen]

On Wed, Feb 18, 2015 at 4:58 PM, Jens Frederich <jfred...@gmail.com> wrote:

25a and 30a font size? This is big. Do you use a 5k iMac? I'm using a Chromebook Pixel with 14a.

It is rather hard to use pixel sizes for anything since the fonts change a lot depending on the kind of display you have. Also, age plays a role in how large of a font you prefer when writing code. I tend to target something around 45-50 lines on a 15 inch 16:10 display and around 65-70 lines on a 27 inch display.

The new font changes looks great btw, though I have to adjust font sizes again, now :)

--

J.

[Jacek Masiulaniec]

This is great. The only regression I had is that it broke my habit of pressing cmd+r, which used to widen the scrollbars for me (but kept the font size unchanged). It made the layout box look more like a square, which made it easier to move panes around, but also to aim at the scrollbar.

I worked around this by bumping Scrollwid like so:

-#define Scrollwid scalesize(display, 12)

+#define Scrollwid scalesize(display, 16)

... which is what I should have done long ago instead of depending on cmd+r.

Jacek

--

[Jordi Bunster]

Whoa, I had no idea cmd+r existed. Funny how you can have a super
opinionated, spartan program like Acme and it still surprises you with
features you didn't know about.

[Russ Cox]

On Wed, Feb 18, 2015 at 2:00 PM, Jordi Bunster <jo...@bunster.org> wrote:

Whoa, I had no idea cmd+r existed. Funny how you can have a super
opinionated, spartan program like Acme and it still surprises you with
features you didn't know about.

It's not a feature. It's a hidden keystroke to toggle retina vs non-retina mode, to debug the effect of moving a window from a retina to non-retina display. It will go away once the retina (high-DPI) stuff is stable.

Russ

[Jens Frederich]

On Wed, Feb 18, 2015 at 6:04 PM, Russ Cox <r...@swtch.com> wrote:

On an Apple Retina MacBook Pro or on a 5k iMac (roughly same DPI), a pixel-doubled euro.8.font and LucidaGrande/30a are about the same size. Unless you use the comma syntax, the size is automatically doubled in high-DPI mode, so saying font=/mnt/font/F/14a/font will get F at 28a on the high-DPI display.

All that said, I don't believe there is code in src/cmd/devdraw's x11 side to report display DPI, so unless you added it, it seems like 14a on the Chromebook Pixel would be an actual 14a.

No there is not x11 code to report display DPI. Do you plan to add this feature? If not, is should be marked as OSX only feature at font(7).

 

That'd be very tiny at the 239 DPI of the Pixel. But maybe you like your fonts tiny.

 

Sure 14a is too small on high-DPI displays. I've used 10a on low-DPI displays for years. I'd correct it to 20a. My mistake.

Jens

[Jens Frederich]

On Wed, Feb 18, 2015 at 7:52 PM, Jacek Masiulaniec <jacek.ma...@gmail.com> wrote:

This is great. The only regression I had is that it broke my habit of pressing cmd+r, which used to widen the scrollbars for me (but kept the font size unchanged). It made the layout box look more like a square, which made it easier to move panes around, but also to aim at the scrollbar.

I worked around this by bumping Scrollwid like so:

-#define Scrollwid scalesize(display, 12)

+#define Scrollwid scalesize(display, 16)

 

I've the same workaround. The layout box is too small on high-DPI displays.

Jens

[Russ Cox]

The layout box is the same size on low and high DPI displays IF devdraw knows the DPI of the display.

If you're having trouble with high-DPI X11 displays, please send a patch to devdraw that will pick up the display DPI so it can be communicated to the rest of the graphics stack.

Thanks.

Russ

[Jesper Louis Andersen]

On Thu, Feb 19, 2015 at 4:23 PM, Russ Cox <r...@swtch.com> wrote:

If you're having trouble with high-DPI X11 displays, please send a patch to devdraw that will pick up the display DPI so it can be communicated to the rest of the graphics stack.

Unfortunately, this might not be that easy. My hack is to change the displaydpi from 110 to 220 in devdraw.c, which also scales the cursor and such.

[jlouis@lady-of-pain ~]$ xdpyinfo | grep -A 2 '^screen'

screen #0:

  dimensions:    6720x2160 pixels (1778x572 millimeters)

  resolution:    96x96 dots per inch

This is my screen. It consists of two screens, one with 160 dpi and one with 220 dpi. The millimeter counts are completely off, because it looks like it is blindly based on the resolution, which is not reported correctly for these screens. There may be screen for which this works though, and once Wayland comes rampaging through UNIX-land, then anything may happen.

--

J.

[vbnut]

On Thursday, February 19, 2015 at 7:23:26 AM UTC-8, Russ Cox wrote:

If you're having trouble with high-DPI X11 displays, please send a patch to devdraw that will pick up the display DPI so it can be communicated to the rest of the graphics stack.

Did anyone every take Russ up on this?  If its a matter of setting displaydpi:
./devdraw.h:9:extern int displaydpi;
in the x11 code of devdraw, I don't see any evidence of a patch.

I recently purchased a Dell XPS 13 with the QHD display (276 DPI), so I have some motivation to tackle this if nobody else has.

[Jordi Bunster]

I have the same problem on a Mac running X11. Rooting for you.

[vbnut]

OK, I modified src/cmd/devdraw/x11-init.c to set displaydpi, tested that it worked, used codereview create  to create a feature branch, then used codereview upload to upload the change for review (https://plan9port-review.googlesource.com/#/c/1470/).  When I look at review, however, it includes a bunch of other changes that I didn't intend to include (all the modifications made by lib/moveplan9.sh - since my $PLAN9 isn't /usr/local/plan9).  What did I do wrong, and how do I create/upload a review that contains only x11-init.c?  Is there some way to remove the extra files from the existing review or do I need to create a new one?

    - Peter

PS: I have bit of experience using git, but I'm pretty much a novice.