unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Brahimi Saifullah <brahimi.saifullah@gmail.com>
To: martin rudalics <rudalics@gmx.at>
Cc: 51995@debbugs.gnu.org
Subject: bug#51995: 29.0.50; `string-pixel-width' depends on the current window width
Date: Sat, 20 Nov 2021 18:42:01 -0300	[thread overview]
Message-ID: <84h7c67bdi.fsf@gmail.com> (raw)
In-Reply-To: <84czmvbepd.fsf@gmail.com>

>Since 'window-text-pixel-size' has to deal with arbitrary buffers, it is
>not a good idea to set X-LIMIT or Y-LIMIT to very large values.  The
>doc-string of 'window-text-pixel-size' explicitly warns about X-LIMIT
>that
>
>   Since calculating the width of long lines can take some time, it's
>   always a good idea to make this argument as small as possible; in
>   particular, if the buffer contains long lines that shall be truncated
>   anyway.

I saw the warnings, but I'm unsure of their validity.
Here are some benchmarks that I did.  Each form was run on a fresh emacs -Q.
Apologies in advance if there is something wrong about them:

;;; X-LIMIT nil (window width is the limit)
(benchmark-run 100000
  (save-window-excursion
    (with-temp-buffer
      (set-window-buffer nil (current-buffer))
      (insert "foo")
      (car (window-text-pixel-size nil (point-min) (point))))))
;; (15.551981 588 8.272839)

(benchmark-run 100000
  (save-window-excursion
    (with-temp-buffer
      (set-window-buffer nil (current-buffer))
      (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
      (car (window-text-pixel-size nil (point-min) (point))))))
;; (17.975419000000002 588 8.30243)


;;; X-LIMIT is equal to the width of the string plus 1
(benchmark-run 100000
  (save-window-excursion
    (with-temp-buffer
      (set-window-buffer nil (current-buffer))
      (insert "foo")
      (car (window-text-pixel-size nil (point-min) (point) 25)))))
;; (15.489861 587 8.267005000000001)

(benchmark-run 100000
  (save-window-excursion
    (with-temp-buffer
      (set-window-buffer nil (current-buffer))
      (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
      (car (window-text-pixel-size nil (point-min) (point) 873)))))
;; (17.98802 587 8.421413)


;;; X-LIMIT is unreasonably large
(benchmark-run 100000
  (save-window-excursion
    (with-temp-buffer
      (set-window-buffer nil (current-buffer))
      (insert "foo")
      (car (window-text-pixel-size nil (point-min) (point) 1000000)))))
;; (15.508047000000001 587 8.281872)

(benchmark-run 100000
  (save-window-excursion
    (with-temp-buffer
      (set-window-buffer nil (current-buffer))
      (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
      (car (window-text-pixel-size nil (point-min) (point) 1000000)))))
;; (18.031506 588 8.440261)

The limit actually seems to be rather irrelevant.
Long strings take expectedly longer, but it doesn't
seem related to how big or how small X-LIMIT is.

The following use a buffer as WINDOW,
as `string-pixel-width' currently does:

(benchmark-run 100000
  (with-temp-buffer
    (insert "foo")
    (car (window-text-pixel-size
          (current-buffer) (point-min) (point)))))
;; (5.935459 164 2.328032)

(benchmark-run 100000
  (with-temp-buffer
    (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
    (car (window-text-pixel-size
          (current-buffer) (point-min) (point)))))
;; (8.362771 168 2.349145)


(benchmark-run 100000
  (with-temp-buffer
    (insert "foo")
    (car (window-text-pixel-size
          (current-buffer) (point-min) (point) 25))))
;; (5.922218 164 2.350169)

(benchmark-run 100000
  (with-temp-buffer
    (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
    (car (window-text-pixel-size
          (current-buffer) (point-min) (point) 873))))
;; (7.989145 164 2.2566439999999997)


(benchmark-run 100000
  (with-temp-buffer
    (insert "foo")
    (car (window-text-pixel-size
          (current-buffer) (point-min) (point) 1000000))))
;; (5.933362 168 2.378873)

(benchmark-run 100000
  (with-temp-buffer
    (insert "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore")
    (car (window-text-pixel-size
          (current-buffer) (point-min) (point) 1000000))))
;; (8.006855 167 2.318854)

It's a lot more efficient to use a buffer, but the difference
between the limits themselves continue to be insignificant.

--------------------------------------------------------------------------------

>'string-pixel-width' and the accompanying change of
>'window-text-pixel-size' are broken in many ways, see also
>
>   https://mail.gnu.org/archive/html/emacs-devel/2021-11/msg00339.html
>
>If you see a problem that is not mentioned there, please tell us.

Yes, those seem to be the exact problems I was experiencing.

>I hopefully fixed most of the issues here but cannot send you a patch at
>the moment to test because my local copy is completely out of synch with
>master.  So please bear with me.

Take your time :)





  parent reply	other threads:[~2021-11-20 21:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-20  5:04 bug#51995: 29.0.50; `string-pixel-width' depends on the current window width Brahimi Saifullah
2021-11-20  7:20 ` Eli Zaretskii
2021-11-20  8:48 ` martin rudalics
2021-11-20  9:35   ` Lars Ingebrigtsen
2021-11-20 21:36 ` Brahimi Saifullah
2021-11-20 21:42 ` Brahimi Saifullah [this message]
2021-11-21  6:34   ` Eli Zaretskii
2021-11-21  9:12   ` martin rudalics
2021-11-21 18:38 ` Brahimi Saifullah
2021-11-22  9:28   ` martin rudalics
2021-11-22 11:04     ` Lars Ingebrigtsen
2021-11-22  0:53 ` Brahimi Saifullah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84h7c67bdi.fsf@gmail.com \
    --to=brahimi.saifullah@gmail.com \
    --cc=51995@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).