From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id B5C7E227C6 for ; Fri, 10 May 2024 21:43:20 +0200 (CEST) Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Fri May 10 15:40:09 -0400 2024 Received: from mimir.eigenstate.org (localhost [127.0.0.1]) by mimir.eigenstate.org (OpenSMTPD) with ESMTP id acc85234 for <9front@9front.org>; Fri, 10 May 2024 12:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eigenstate.org; h= message-id:to:subject:date:from:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=lNFfxPfU1pvY 4vw4EsL5aBc5W50=; b=MEYC3eFIDsRjLGwLtJfgxee/M9QlDbm1AuKDcwZubOTR NGBMmsu0a72jXM60jhFQprQRnDO56qhH2cT2ByYaK9ivLHvsLxiMW7leBpJRT4Ch tQK9mG3O1G/jkaNAFQ7FbFM26QDKHVZptzLQ5kQgcGtNpBlA743ZtPKGaSnhcR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eigenstate.org; h=message-id :to:subject:date:from:in-reply-to:mime-version:content-type :content-transfer-encoding; q=dns; s=mail; b=HvjKN76BeICb8uwPAXx hDd6DwuRYbgTJeIJHVtl9YWsP6BFQ259vGjovhk5h6UqXS5aJ7ZWgFwa9mom/eFr 005P5/iokDaJn7BKlkLgWuccw6Qin7U8rGvl0vupDrJWb8bp7dIY7VS2VlCriuhZ Mvfj97MsyTQIq/L+1nY9FHlA= Received: from abbatoir (pool-108-6-24-2.nycmny.fios.verizon.net [108.6.24.2]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id c51e59f0 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Fri, 10 May 2024 12:40:03 -0700 (PDT) Message-ID: To: 9front@9front.org Date: Fri, 10 May 2024 15:40:02 -0400 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: proven advanced markup-aware firewall-based CMS backend Subject: Re: [9front] [PATCH] rio: resize border and scrollbar based on font Reply-To: 9front@9front.org Precedence: bulk Quoth Jacob Moody : > /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.