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

[N. Jackson]

At 04:21 -0400 on Saturday 2014-02-22, Eli Zaretskii wrote:

>> From: nljlistbox2@gmail.com (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.

I saw the same general behaviour with all of the few pages I
visited. The one I did my detailed examination on was
http://www.gnu.org/distros/screenshot.html.

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

Yes, with "emacs -Q".

For example this recipe (where the maximize before loading the page is
just to get the image big enough to be taller than the frame (as Eww
(sensibly, I think) resizes images to fit in the frame when it loads a
page). On my machine this makes the image slightly less than twice the
height of the display.

    emacs -Q
    M-x toggle-frame-maximized RET
    M-x eww RET http://www.gnu.org/distros/screenshot.html RET
    M-x toggle-frame-maximized RET

>> 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.

Yes. That's what happens.

If it's the current intended behaviour, then that is what it is. I
raised this bug report to point out that the behaviour I observe is
sub-optimal from a user-experience point of view, Emacs could be better
in this regard. Consider it then, perhaps, as a wishlist item for Emacs
25 or 26!

I myself am a bit ambivalent about this suddenly having images in
Emacs. I'm not sure that I like them, and I'm certain that I don't need
them. However to be able to view web pages within Emacs seems useful,
and in checking out this functionality in Emacs 24.3.50 I noticed the
perceived deficiencies reported, so I reported them, because I believe
that it's hard to improve something when one isn't aware of what might
be wrong with it.

>> 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?

The first line of it, but if there were a two-line gap instead of a
one-line gap between the image and its caption, it wouldn't be visible.

But if the intended behaviour is that the window should scroll to bring
the line below the image to the top of the window when a line or two
below the image becomes visible, then it is impossible in general with
an imgage taller than the frame to see text below the image that
pertains to it while the image is still in view (unless that text
happens to be only one or two lines long).

> 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.

    M-x describe-font RET

    name (opened by): 
-xos4-Terminus-normal-normal-normal-*-12-*-*-*-c-60-iso10646-1
           full name: 
Terminus:pixelsize=12:foundry=xos4:weight=normal:slant=normal:width=normal:spacing=110:scalable=false
                size: 12
              height: 12
     baseline-offset:  0
    relative-compose:  0

>> 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.

Fair enough. From ignorance one may stipulate impossible
requirements. Yet it's not impossible that in such naive requirements
lies a germ of a better future 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.

I believe human perception requires more than that.

I don't know about pixel-level scrolling. Naively (again) I feel that
even charcter-wise line-by-line scrolling would be far smoother that the
current observed behaviour if "behind" the image there were inserted as
many empty lines of text as needed to span the height of the image.

> 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.

Fair enough. I was ignorant of the fact that the failings of the current
behaviour were intentional, due to contraints of the existing infrastructure.

>> 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.

>From the point-of-view of an ideal interface, yes it should, in my
opinion, be symmetrical. But the ideal can never be realised or it is no
longer ideal, and in this case, obviously there are very practical
reasons as well.

> Again, if the user doesn't have a chance of seeing each part
> of the image at least once, please describe the details.

It works in the way you describe aside from the "glitches" (below)
and those allow the user to see the same part of the image more than once!

>> 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.

If it is reproducible on demand, I don't see the pattern. That's what I
meant by the "occasional" in my description.

However, using the recipe provided earlier in this message, I saw it
happen thrice while scrolling up and down the page maybe seven or eight
times, so it is not uncommon on my set up.

I only see it happenning going down the page. (I had previously seen a
very similar "glitch" going up the page, but I realise now that that was
with an image in a Gnus message not an image in Eww -- I don't know if
there is any commonality in the code involved.)

>> 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.

After the "glitch" occurs at the beginning of scrolling an image, when
the cursor emerges in the text below the image it is at the ends of the
lines instead of in the first column. This seems to happen consistently
after the "glitch" occurs.

> Thanks.

Thank you.

N.