From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: dalanicolai Newsgroups: gmane.emacs.devel Subject: Re: Question about (excessive?) ram usage when many overlays (with large vscroll) Date: Thu, 28 Apr 2022 18:48:20 +0200 Message-ID: References: <87levs2enb.fsf@yahoo.com> <87zgk5za1w.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000024db3705ddb9b21a" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28774"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs Devel To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 28 18:49:29 2022 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 1nk7Ka-0007Mj-VP for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Apr 2022 18:49:29 +0200 Original-Received: from localhost ([::1]:54078 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nk7KZ-0007R1-Rb for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Apr 2022 12:49:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nk7Ji-0006ib-9K for emacs-devel@gnu.org; Thu, 28 Apr 2022 12:48:34 -0400 Original-Received: from mail-yw1-x112a.google.com ([2607:f8b0:4864:20::112a]:38608) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nk7Jg-00066g-4D for emacs-devel@gnu.org; Thu, 28 Apr 2022 12:48:33 -0400 Original-Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-2f7d7e3b5bfso59533717b3.5 for ; Thu, 28 Apr 2022 09:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CPkkfOY/EFJ4lsKf83fS+VObdrM9rnN+zFk+BBppl1w=; b=acgU+uUnZhUIGxqkeAR8Fow71nbNc4Ad3Ds5iyjiWSfFRbzF3Vd8nZMl95jtZtDEz/ 6AyC7iRzIftIv17YezGRY8G9Z3XBh9nqLQdhfLQfmTI4l52/Zk0brAwTN29b9GlU5inZ L0J/WGoLBeb/tYrLirJ6IDYlZkQvuD8N5jmwB2QWpHDtyFdtmX13qBQcRpJSQxcDssFw fK41g1LpFCZb3qKwYVJCYttWYfMRy8g1jCjJ0KaiiaBBCEDDIK2oHD/2oKOsce6uhajd YtqcWiXdAXJvhDdfescs33Wc0YpnFtmdErdqb8s4LmBvBBvjaeWsnIVxhS+aFyw16Hjt tfjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CPkkfOY/EFJ4lsKf83fS+VObdrM9rnN+zFk+BBppl1w=; b=sb7AqczYXnCD6mnllOGm90KOtr1EFJGOUppYD3rSZyRp/k2mlhDnYhSBRQ4rD6zMEN NSEP/gN/nIkBPLqqsx/dubKk5avd/kC/S3UWYgY0G4wDIkaCAxIxTTUN83SIcHEM8MR/ vI+w17wBfU4MEctUpk4ps4V3hjZx6FXvtmuDJ2N711Qq00WqhUxeuZijOlR+e0XfJVMQ w1sV/pGHxhu8i/ZJ9peo79BiA53D4SERZ0wls1u2uYl5QgxWUquqqiFsxThwUX1Xpl4d COOmKzZEOHVZSiLdwq5fOxovxY3Fh8wkOwbLHvakE3+FyButNNwcinBn8XfFZ6vm3dci smBw== X-Gm-Message-State: AOAM532raXfPAI2NijFrtvaPku/uNrOJ4sKiSVUy3DN/v0gDOEcGsDAN 3UV0SqE6ETo05YUpqqXZCgUcw4Hm+clmaORqY5FL3KwGBjHDzg== X-Google-Smtp-Source: ABdhPJy7Ns9JMenwJJYuciTKOX1Q51Yg2EfFPdZGh5Lk/fdibVy0FlhJl7AqPWysqupa5YzzURcmHaPYpIXAUbHwecs= X-Received: by 2002:a0d:cb0e:0:b0:2f4:e361:4341 with SMTP id n14-20020a0dcb0e000000b002f4e3614341mr34367351ywd.452.1651164511000; Thu, 28 Apr 2022 09:48:31 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::112a; envelope-from=dalanicolai@gmail.com; helo=mail-yw1-x112a.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, T_SCC_BODY_TEXT_LINE=-0.01 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" Xref: news.gmane.io gmane.emacs.devel:288946 Archived-At: --00000000000024db3705ddb9b21a Content-Type: text/plain; charset="UTF-8" B.t.w to see how things work when adding the `set-window-start`, you could uncomment that function in the `image-roll-next-page` function. You will find that the `image-set-window-vscroll` at the end of the `image-roll--redisplay` function has no effect. To see how things work when adding the redisplay, you could additionally uncomment it at the end of the `image-roll--redisplay` function. On Thu, 28 Apr 2022 at 18:28, dalanicolai wrote: > Thank you Po, for your explanations. Indeed this clears things > up a little, but unfortunately my question was not 'precise enough', > for the answer to 'solve' the issue that motivated this question. > (I wanted to keep my `image-mode.el` out of the question, but I > guess it is necessary to add it to explain the issue I am experiencing). > > So I have rewritten `image-mode.el` to scroll by `line + vscroll` instead > of using vscroll only. This solves the issue with the RAM usage for > 'large documents'. > Additionally, it made the code a little 'simpler', which is a welcome > 'side effect' > (I got rid of the 'gap' (page separation) overlays, and instead added > margins > to the images. So now the buffer contents is just single spaces on > separate > lines, where the number of lines is equal to the number of `images/pages`. > The 'gap' color can be configured by adding the overlay's face background). > It seems to work mostly correct (the 'scrolling' look a tiny bit less > smooth than > with the pure vscroll version, but I would say it is very acceptable). > > Anyway, I hope someone can quickly have a look at the issue explained below > (this should take less than a minute). So let me quickly provide some > context > for the issue. > > Currently, each overlay is overlaid on a single space on separate lines. > So the > contents of the buffer is a single space (holding a page overlay) on every > line. > So to jump to the next page, I can simply use 'forward-line'. Now this > works fine > when the page is 'off-window` but when the next page is already within view > ('on-window'), then going to the next line does not position that line at > the top of > the window, nor makes it the current `window-start. To get it at the top > of the > window, I could subsequently call `(set-window-start nil (point))`, > but then subsequently, `set-window-vscroll` does not work. To make > `set-window-vscroll` have effect, I can add a `redisplay` just before I > call it. > This works, but the 'jump' gets very/unacceptably ugly (you see the > 'recentering' > steps taking place). > > However, when the next page is 'off-window' than using the 'forward-line' > works > directly, and the page jump looks smooth. > > So to reproduce it from `emacs -Q` you can just load the `image-roll.el` > file that I > will attach here, then do `M-x image-roll-demo` and scroll down using the > arrow > keys until you see the page transition between page one and two. Now press > the > `page down` (PgDn) button to jump to the next page. > > Because page two is already 'on-window' this only moves the cursor one > page down. > > If you now press a second time `PgDn` then, because page 3 is still > `off-window`, > the jump takes place how it should. > > I would be happy, if someone could tell me how I could 'solve' this issue. > Otherwise, > all scrolling functions work fine, although I did not yet take care of the > 'edge cases' > (i.e. first and last page). Also, I did not update the docstrings yet, so > I am not asking > for feedback on those. My only question is if someone could have a look at > what I am > describing above. > > On Thu, 28 Apr 2022 at 14:07, Po Lu wrote: > >> dalanicolai writes: >> >> > I have a question about this, namely: how to make a line the 'window >> > start'? Using 'set-window-start` does not work. >> > >> > From 'emacs -Q' (which starts within the scratch buffer), immediately >> > evaluate >> > >> > (set-window-start nil (point)) >> > >> > to set the 'new' window start. Subsequently do >> > >> > (set-window-vscroll nil 1) >> > >> > it will scroll from the start of the buffer, and not from the 'new' >> > window start as I would expect >> >> That's because the point is obscured after the vscroll is applied, so >> the display is recentered. You have to move point to some location that >> is at least partially visible after the vscroll if you set >> `make-cursor-line-fully-visible' to t, or a location that is fully >> visible otherwise. >> > --00000000000024db3705ddb9b21a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
B.t.w to see how things work when adding the `set-win= dow-start`,
you could uncomment that function in the `image-roll-= next-page`
function. You will find that the `image-set-window-vsc= roll` at the
end of the `image-roll--redisplay` function has no e= ffect.

To see how things work when adding the redi= splay, you could
additionally uncomment it at the end of the `ima= ge-roll--redisplay`
function.


<= div class=3D"gmail_quote">
On Thu, 28 = Apr 2022 at 18:28, dalanicolai <dalanicolai@gmail.com> wrote:
Thank you Po, for your explanat= ions. Indeed this clears things
up a little, but unfortunately my= question was not 'precise enough',
for the answer to = 9;solve' the issue that motivated this question.
(I wanted to= keep my `image-mode.el` out of the question, but I
guess it is n= ecessary to add it to explain the issue I am experiencing).

<= /div>
So I have rewritten `image-mode.el` to scroll by `line + vscroll`= instead
of using vscroll only. This solves the issue with the RA= M usage for
'large documents'.
Additionally= , it made the code a little 'simpler', which is a welcome 'side= effect'
(I got rid of the 'gap' (page separation) ov= erlays, and instead added margins
=C2=A0to the images. So now the= buffer contents is just single spaces=C2=A0 on separate
lines, w= here the number of lines is equal to the number of `images/pages`.
The 'gap' color can be configured by adding the overlay's fac= e background).
It seems to work mostly correct (the 'scro= lling' look a tiny bit less smooth than
with the pure vscroll= version, but I would say it is very acceptable).

= Anyway, I hope someone can quickly have a look at the issue explained below=
(this should take less than a minute). So let me quickly pro= vide some context
for the issue.

Current= ly, each overlay is overlaid on a single space on separate lines. So the
contents of the buffer is a single space (holding a page overlay) o= n every line.
So to jump to the next page, I can simply use '= forward-line'. Now this works fine
when the page is 'off-= window` but when the next page is already within view
('on-wi= ndow'), then going to the next line does not position that line at the = top of
the window, nor makes it the current `window-start. To get= it at the top of the
=C2=A0window, I could subsequently call `(s= et-window-start nil (point))`,
but then subsequently, `set-window= -vscroll` does not work. To make
`set-window-vscroll` have effect= , I can add a `redisplay` just before I call it.
This works, but = the 'jump' gets very/unacceptably ugly (you see the 'recenterin= g'
steps taking place).

However, whe= n the next page is 'off-window' than using the 'forward-line= 9; works
directly, and the page jump looks smooth.

=
So to reproduce it from `emacs -Q` you can just load the `image-= roll.el` file that I
will attach here, then do `M-x image-roll-de= mo` and scroll down using the arrow
keys until you see the page t= ransition between page one and two. Now press the
`page down`= (PgDn) button to jump to the next page.

Because p= age two is already 'on-window' this only moves the cursor one page = down.

If you now press a second time `PgDn` then, = because page 3 is still `off-window`,
the jump takes place how it= should.

I would be happy, if someone could tell m= e how I could 'solve' this issue. Otherwise,
all scrollin= g functions work fine, although I did not yet take care of the 'edge ca= ses'
(i.e. first and last page). Also, I did not update the d= ocstrings yet, so I am not asking
for feedback on those. My only = question is if someone could have a look at what I am
describing = above.

On Thu, 28 Apr 2022 at 14:07, Po Lu <luangruo@yahoo.com> wrote:
<= /div>
dalanicolai <dalanicolai@gmail.co= m> writes:

> I have a question about this, namely: how to make a line the 'wind= ow
> start'?=C2=A0 Using 'set-window-start` does not work.
>
> From 'emacs -Q' (which starts within the scratch buffer), imme= diately
> evaluate
>
> (set-window-start nil (point))
>
> to set the 'new' window start. Subsequently do
>
> (set-window-vscroll nil 1)
>
> it will scroll from the start of the buffer, and not from the 'new= '
> window start as I would expect

That's because the point is obscured after the vscroll is applied, so the display is recentered.=C2=A0 You have to move point to some location th= at
is at least partially visible after the vscroll if you set
`make-cursor-line-fully-visible' to t, or a location that is fully
visible otherwise.
--00000000000024db3705ddb9b21a--