Improve gui-metal HiDPI scaling

[afh]

For macOS systems with a Retina Display when using a scaled resolution with more space, it seems the drawterm resolution scaling isn't ideal resulting very small and hard to read font sizes (see screenshots below)

The proposed changes in this PR adjust the drawterm screen size according to the system's scaling.

Before	After

[jxy]

I just change my $font. The whole point of the backend is so that we can use the "physical pixels" instead of the scaled one, because the automatic scaling is terrible to look at. If you want to use the automatic scaled image, can you add it similar to devdraw in plan9port, pressing "cmd-r" would resize the screen and toggle scaling?

[afh]

Thanks for the feedback @jxy. Does changing $font also change the font on the Plan 9 console?

Happy to look into adding toggling screen scaling and resizing via ⌘ R; is this what you were thinking about?

[jxy]

The one in p9p is probably bad analogy, because what you can do with drawterm is only changing the size relying on the window system to scale the low resolution image to your hidpi screen, but not scalesize for all the elements nor properly rendered fonts to the backing pixels.

Given rio can't practically keep window at the same size after resizing up/down and back, I don't see any practical use of dynamic toggling of the system scaling.

If you really want to work with a low resolution image on your hidpi screen, it's probably easier just to add a command line argument to use the apparent screen point instead of the backing pixels. You could avoid calling all those convert to/from backing functions, because the default sizes are in screen points.

I only set font in my profile, as I don't really see anything from the console.

[jxy]

If you really want to "improve" the low resolution display, as it just occurred to me, you could do a just-in-time 2x upscaling of the image and render it to the display. It would be ugly for rendered freetype fonts, but it would be alright for the original bitmap fonts.

In the current code, I have the EPX 2x upscaling for the cursor,

drawterm-metal-cocoa/gui-metal/screen.m

Lines 218 to 244 in 1776e8a

	for(a=0; a<2; a++){
	for(y=0; y<16; y++){
	for(x=0; x<2; x++){
	pc = planes[a][x+2*y];
	pu = y==0 ? pc : planes[a][x+2*(y-1)];
	pb = y==15 ? pc : planes[a][x+2*(y+1)];
	pl = (pc>>1) | (x==0 ? pc&0x80 : (planes[a][x-1+2*y]&1)<<7);
	pr = (pc<<1) | (x==1 ? pc&1 : (planes[a][x+1+2*y]&0x80)>>7);
	ful = ~(pl^pu) & (pl^pb) & (pu^pr);
	pul = (ful & pu) | (~ful & pc);
	fur = ~(pu^pr) & (pu^pl) & (pr^pb);
	pur = (fur & pr) | (~fur & pc);
	fbl = ~(pb^pl) & (pb^pr) & (pl^pu);
	pbl = (fbl & pl) | (~fbl & pc);
	fbr = ~(pr^pb) & (pr^pu) & (pb^pl);
	pbr = (fbr & pb) | (~fbr & pc);
	planes2[a][2*x+4*2*y] = (pul&0x80) | ((pul&0x40)>>1) | ((pul&0x20)>>2) | ((pul&0x10)>>3)
	| ((pur&0x80)>>1) | ((pur&0x40)>>2) | ((pur&0x20)>>3) | ((pur&0x10)>>4);
	planes2[a][2*x+1+4*2*y] = ((pul&0x8)<<4) | ((pul&0x4)<<3) | ((pul&0x2)<<2) | ((pul&0x1)<<1)
	| ((pur&0x8)<<3) | ((pur&0x4)<<2) | ((pur&0x2)<<1) | (pur&0x1);
	planes2[a][2*x+4*(2*y+1)] = (pbl&0x80) | ((pbl&0x40)>>1) | ((pbl&0x20)>>2) | ((pbl&0x10)>>3)
	| ((pbr&0x80)>>1) | ((pbr&0x40)>>2) | ((pbr&0x20)>>3) | ((pbr&0x10)>>4);
	planes2[a][2*x+1+4*(2*y+1)] = ((pbl&0x8)<<4) | ((pbl&0x4)<<3) | ((pbl&0x2)<<2) | ((pbl&0x1)<<1)
	| ((pbr&0x8)<<3) | ((pbr&0x4)<<2) | ((pbr&0x2)<<1) | (pbr&0x1);
	}
	}
	}

You could do the same for the whole image, or just use a cheaper nearest neighbor 2x upscaling.

This way, we can avoid the uncontrollable upscaling by the macOS window system, and have a sharper image of low resolution plan9 display in the high resolution drawterm.