Subject: Re: bug#16840: 24.3.50; Jerky motion and up/down asymmetry scrolling images in Eww

From: Eli Zaretskii <[email-masked]>
Date: Sat, 22 Feb 2014 10:21:41 +0200

> From: [email-masked] (N. Jackson)
> Date: Fri, 21 Feb 2014 21:51:47 -0400
> 
> With an image taller than the window, scrolling behaviour is jerky and
> asymmetrical in Eww.

Please provide a URL to such an image, since the exact behavior
depends on the relative sizes of the image and the default font.

Also, does the behavior you describe happen in "emacs -Q", or do you
need some non-default customizations to see what you describe?

> Scrolling Downwards with <down>
> ===============================
> When scrolling down the page (pressing <down> <down> <down> ...), when
> the cursor reaches the line above the image, it stops going to the next
> line. Instead, the image is smoothly scrolled up in to view. I am told
> that this is the designed behaviour.

Yes, that's the design.

> When the line with the cursor disappears off the top of the window, the
> cursor jumps to the image. There is a slight jerk when this happens,
> which might be worth eliminating.

The jerk should bring the top of the image to the top of the window.
If that is what happens, then that's the intended behavior.

> At some point (and it's approximately when two lines are visible below
> the image) the cursor jumps to the line below the image, and, most
> unfortunately, the window scrolls so that that line is the top line in
> the window. This results in a huge jerk, and it also means that the
> image has disappeared before you can read a caption directly below it.

Wasn't the caption visible before the jump?

In any case, it's impossible to reason about the described behavior
without knowing the image size and size of the font used to display
text around it.

> If the designed behaviour mentioned three paragraphs above this one is
> correct, then it would seem better, when the image has scrolled up
> sufficiently for the line below it to be visible, if the cursor then
> jumped to that line, but stayed on it while additional <down> presses
> continued to scroll the image smoothly upwards until the bottom of the
> image had disappeared off the top of the window, and then the <down>
> presses resumed doing next-line in the normal way.

This is next to impossible with the current design of scrolling in
Emacs.  The goal of pixel-level scrolling in Emacs 24 is to allow the
user a chance to see every part of the image at least once.  If that
goal is reached, the rest are deeper limitations of the current
design, and will require significant changes, not just in the area of
scrolling tall images.

> Scrolling Upwards with <up>
> ===========================
> Currently when scrolling upwards from below an image the behaviour is
> completely different (and worse) from that observed when scrolling
> downwards from above one. Surely the upward-going behaviour should be
> symmetrical with the downward-going behaviour?

No, it should not (and cannot) be symmetrical, for boring technical
reasons.  Again, if the user doesn't have a chance of seeing each part
of the image at least once, please describe the details.

> Furthermore, while scrolling one key press at a time like this, there
> are occasional "glitches" where the image jumps back to the position it
> was in immediately before scrolling started.

I don't see it with images I tried.  It would be best if you could
provide a reproducible recipe, with a specific image, starting from
"emacs -Q", that shows these glitches.

> Additionally (and I think this may only happen at the same time as the
> "glitches" mentioned above), the cursor column changes from the first
> column for no obvious reason, and then appears at the ends of lines of
> text instead of at the beginning of them.

Likewise.

Thanks.