From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED
	autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 27900 invoked from network); 23 Dec 2021 16:23:38 -0000
Received: from 4ess.inri.net (216.126.196.42)
  by inbox.vuxu.org with ESMTPUTF8; 23 Dec 2021 16:23:38 -0000
Received: from mail.9lab.org ([168.119.8.41]) by 4ess; Thu Dec 23 11:14:57 -0500 2021
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=9lab.org; s=20210803;
	t=1640265115;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=fCN9whAzHJ9DMFnUzERPWvAMuBkxceRkvysxBVu3uxM=;
	b=ipCK2G7XS1rZlZasSWpbJDawEureAQlG/jHq3UG7kGMVdwaskUeeAvu6bFjfEYOSzqQvvP
	WYQa8tB6raP9CyMwLzadcdwt7IShoWZfvGXRFA/Gw3Q4NeLaL7MDkmxjdzeyX3yhZnFoG0
	V444Q4wt4WxDkFtww5UGmMaR8V1OFWI=
Received: from pjw (host-185-64-155-70.ecsnet.at [185.64.155.70])
	by mail.9lab.org (OpenSMTPD) with ESMTPSA id 88ae0f7f (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO)
	for <9front@9front.org>;
	Thu, 23 Dec 2021 14:11:55 +0100 (CET)
Message-ID: <55709FEE2D9765358A19BC6B32EA68D3@9lab.org>
To: 9front@9front.org
Date: Thu, 23 Dec 2021 14:11:53 +0100
From: igor@9lab.org
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: private firewall database 
Subject: Re: [9front] hidpi
Reply-To: 9front@9front.org
Precedence: bulk

Quoth Philip Silva <philip.silva@protonmail.com>:
> Ah ok, interesting.  The one I remember is actually a similar y
> offset problem but in the opposite side (drawing into the now thicker
> border on top).  That was in rio though.  I must admit I mechanically
> copied the changes from plan9port where it seemed reasonable and then
> continued replacing where it looked right.  So that code has kind of
> heuristic reasoning :) 

Yeah, I tried to eyeball the changes and copy things mechanically
as well, however, that did not succeed in fixing this issue. So
the only way is to actually understand the code, debug the issue,
and fix it ☺

The following shows the glitch (note the white line at the bottom), it
is fortunately easy to reproduce:

• https://invidio.xamh.de/watch?v=iLekQrxycaM

…opening acme and simply resizing the column to the right is all
that is needed.

> Cool I'll probably look first into trying some of the ideas mentioned
> once I'm in reach of my laptop again

Sounds good. I hope to find some time over the X-mas break to make
progress debugging and hopefully fixing it…

> -------- Original Message --------
> On Dec 22, 2021, 9:39 AM, < igor@9lab.org> wrote:
> Quoth Philip Silva <philip.silva@protonmail.com>:
> […]
> > - glitches: the borders aren't calculated correctly (3rd patch for rio and acme is very wip)
> […]
> By glitches, do you mean issues like the one here:
> • https://9lab.org/img/plan9/acid.png
> …where there is an issue in computing the column growth ⁽¹⁾ (I think)
> manifesting itself as an artefact that looks like a white line at the
> bottom of an acme column. On small res displays this isn't
> noticeable, however, on high-res screens it is annoying.
> I stopped half way through due to lack of time debugging this
> (still on my todo list), and was wondering if you observed the
> same glitch.
> ⁽¹⁾ … https://9lab.org/plan9/debugging-with-acid/