Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[ori@eigenstate.org]

Quoth Jacob Moody <moody@posixcafe.org>:
> /dev/theme is not merged so you can not hang your solution off of that if you'd like it merged.
> Here's how I would approach this:
> 1. fix code assumptions about rio's border size, or use an environment variable or something.

This is probably a good idea regardless of the rest. Bonus if
the fix made programs completely ignorant of, and oblivious to,
border widths.

> 2. Attempt a transparent scaling, perhaps something in libdraw that just stupidly does 2x upscaling of draw ops
>    a. evaluate how much this sucks, maybe it works fine maybe it creates a shit experience idk
> 3. Failing that we give up and add $scale and make it every programs problem to distinguish what should be scalled (things like UI elements) vs not (fonts and images)
> 
> I don't see any other appetizing option at the moment, perhaps someone else does.
> 

It strikes me that font size may not be the worst thing to hang
the scaling off of; outside of Plan 9, many things draw in units
of 'em', which is the width of a capital 'M' in the current type
face.

There are issues around that (what do we do when we scale a 1 pixel
line by 37%?), and I don't know how to solve them.

With scaling, there's a lot of options we can take for behavior,
and all of it sucks in one way or another.

The one option we have implemented now ("implement for a reasonable
range of display densitys, and don't scale") is the only one that
doesn't degrade quality. From there, we start to make tradeoffs.

	- What do we do with images?
	- What do we want to do with non-integer scale multiples?
	- How about a mix of images and text? should we scale the
	  images? how? (imagine, eg, a mapping program)
	- If we have multiple monitors (yeah, not implemented yet,
	  but I *really* want it), how should scaling behave?
	- Do we want antialiasing in devdraw to make fractional line
	  widths look acceptable.

I haven't put a ton of thought into this. It may be possible to
get a viable tradeoff with some split between libdraw and devdraw,
but there's nothing that jumps out to me as obviously correct.