From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jimmy Yuen Ho Wong Newsgroups: gmane.emacs.devel Subject: Need `truncate-string-to-pixel-width` and `glyph-pixel-width` functions in C Date: Wed, 23 Oct 2024 06:01:18 +0100 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d90f6b06251dc84d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39594"; mail-complaints-to="usenet@ciao.gmane.io" To: Emacs-Devel devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 23 07:02:27 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1t3TVr-000ADZ-0i for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Oct 2024 07:02:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t3TVW-0001hk-6A; Wed, 23 Oct 2024 01:02:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t3TVU-0001hS-No for emacs-devel@gnu.org; Wed, 23 Oct 2024 01:02:04 -0400 Original-Received: from mail-qv1-xf2b.google.com ([2607:f8b0:4864:20::f2b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t3TVR-00009Q-Hw for emacs-devel@gnu.org; Wed, 23 Oct 2024 01:02:03 -0400 Original-Received: by mail-qv1-xf2b.google.com with SMTP id 6a1803df08f44-6cbe3e99680so35362206d6.3 for ; Tue, 22 Oct 2024 22:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729659715; x=1730264515; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=dZy1beXBHC3tsiPLF6cTwfvhspWlKGqLAGleGTfLMvw=; b=ZwkSVVrCG74S/NDqh0MIv9Fn3sZY1L9rhNNfdLFn6gmfejpu5Re4vKv4uxQcZm502X cbID9RxDK9DmB+ZdHDZFKQ//kj9THdDX7UETTffBP83Fv3xKmGJPYC7t78Un6aQvOM/l r7EpodslONyFc4oGPtfU5oDxq7khCKPNVoHZ3pjZ8MpH/iw9QU9H1D2H8M6afnteHQLX xgF0Y48B5QBSYvnRMIReY65IgFnthxWIXiFSbS2puLIKZhKwYCupvg3tDKhQk9y/1zX4 Z6wrmKDXvBR9jH/ZG8dOrKR5ZCMpNLcYz/KsrrFLTznk5LHjoc1RCnYjkY/D09mcqidR zoDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729659715; x=1730264515; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dZy1beXBHC3tsiPLF6cTwfvhspWlKGqLAGleGTfLMvw=; b=KTI/+iHXjtqZNiJue/FGqPhY9H+MqjFvcSi5iH49S9uuyIhQp9KiwhyWH1wFXajFnI uw+cWByGoAUFLYkduF0YxzvI3hfwYUr18z56/cx7TsY2A/J/6+Liz+DqTlSGBzEtqfud E/dY1G56eP0X+whhUS2Jt8JcbNaSHEbW8sTB7+wTm5SRB7lzQknF6gCbF+1TnSIOB5kP 4zk5IO5Qi0heQ8FnbvdrdzmlQvATthHxnlM7e4agw6062m7ZaFf0q9x88IKXGOiFZCMX sWA5lZyrUIHybyUq1HX7zx8m3iO0U1+zJrGvMXqeqaWXfz9lmzOpEWSN46eZgXbj7pYc yxxw== X-Gm-Message-State: AOJu0YwoTavkAt/LcRGiRa1uSG4MErKjqUjYwDgdOHwnGucsAeBcmV1N 9GnZPIERvZ9pWA53uCQLczbWPdtM825zKPL7+7lTtIk0zmeJvAevZHYUUpIXLGhGn7jg0ZJ24hY bNT1BKHIa4oPZ1oUCyipgkDws3hA+GQBF X-Google-Smtp-Source: AGHT+IEAnRq06cinKxJkz0W11bSsevDSaJ3mEMweEXwsjJPy1tB/3Okj7sotALwZs8+KQn2258TMTVLwojXKiDPU9Ns= X-Received: by 2002:a05:6214:460f:b0:6cb:a170:68ec with SMTP id 6a1803df08f44-6ce3424f577mr26952796d6.33.1729659714201; Tue, 22 Oct 2024 22:01:54 -0700 (PDT) Received-SPF: pass client-ip=2607:f8b0:4864:20::f2b; envelope-from=wyuenho@gmail.com; helo=mail-qv1-xf2b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324762 Archived-At: --000000000000d90f6b06251dc84d Content-Type: text/plain; charset="UTF-8" Dear emacs-devel, Recently I've been trying to mold Corfu to render every string in every face in pixel precision but I've run into some slight performance issues when truncating strings. The motivation for this is `truncate-string-to-width` not only does not speak pixels, but also doesn't understand composed characters such as emojis. It just chops off the emoji byte sequence in the middle as described in the PR, so I had to write a custom `truncate-string-to-pixel-width` function using `string-glyph-split` and `string-pixel-width` to measure character widths, which seems... silly. I've looked into how to get the width of a glyph from a font object by employing some dark magic of undocumented internal functions and wrongly documented functions such as `char-displayable-p`, `font-info`, `lglyth-width`, `lgstring-glyph`, `open-font` etc in combination of `composition-get-gstring`, which is correct and fast enough.... for glyph strings with no faces. Then I looked into reverse engineering the face font selection process, which quickly pushed the run time up 2 orders of magnitude due to the anonymous face + face attribute inheritance + face lists madness. Then when I realized I still didn't deal with display text properties, I threw my hands up. It'd be really nice if we could have a really performant C function that can truncate strings correctly and preferably in pixel precision. Alternatively, a `glyph-pixel-width` that implements a fast path in C that's somewhat akin to the process I described above, but also handles display text properties correctly would be nice. I don't really know enough about Emacs C internals WRT to font rendering to implement this so I'm just throwing this idea out there. Does this make sense? Jimmy Yuen Ho Wong --000000000000d90f6b06251dc84d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear emacs-devel,

Recently I'v= e been trying to mold Corfu to render every string in every face in pixel pr= ecision but I've run into some slight performance issues when truncatin= g strings. The motivation for this is `truncate-string-to-width` not only d= oes not speak pixels, but also doesn't understand composed characters s= uch as emojis. It just chops off the emoji byte sequence in the middle as d= escribed in the PR, so I had to write a custom `truncate-string-to-pixel-wi= dth` function using `string-glyph-split` and `string-pixel-width` to measur= e character widths, which seems... silly.

I've looke= d into how to get the width of a glyph from a font object by employing some= dark magic of undocumented internal functions and wrongly documented funct= ions such as `char-displayable-p`, `font-info`, `lglyth-width`, `lgstring-g= lyph`, `open-font` etc in combination of `composition-get-gstring`, which i= s correct and fast enough.... for glyph strings with no faces. Then I looke= d into reverse engineering the face font selection process, which quickly p= ushed the run time up 2 orders of magnitude due to the anonymous face=C2=A0= + face attribute in= heritance=C2=A0+ fa= ce lists madness. Then when I realized I still didn't deal with display= text properties, I threw my hands up.

It'd be really nice if we= could have a really performant C function that can truncate strings correc= tly and preferably in pixel precision. Alternatively, a `glyph-pixel-width`= that implements a fast path in C that's somewhat akin to the process I= described above, but also handles display text properties correctly would = be nice.

I don't really know enough about Emac= s C internals WRT to font rendering to implement this so I'm just throw= ing this idea out there.

Does this make sense?

=
Jimmy Yuen Ho Wong
--000000000000d90f6b06251dc84d--