Re: Displaying scrollable images in a grid-layout

[Eli Zaretskii]

> From: Yuri Khan <address@hidden>
> Date: Wed, 15 Apr 2015 10:17:02 +0600
> Cc: Tassilo Horn <address@hidden>, address@hidden, 
>       Emacs developers <address@hidden>
> 
> > ??? Why does it make sense to show a partial line, when we can show it
> > in its entirety?  Can you explain?
> 
> You assume that the line is a bigger unit than the image, that the
> image is part of the line. However, in PDF viewers, an image of a
> whole page contains many lines of text.

I meant the Emacs screen line, a.k.a. "glyph row" in the display
engine terminology; sorry for not being clear.  A screen line in Emacs
can never be smaller than its largest element, be that some character
glyph, image, or whatnot.

> Many people, when confronted with a need to read documents in PDF
> format, scroll the parts they have already read past the top window
> edge, so that the window edge tracks where they are reading. This way,
> if they are distracted, they can continue reading immediately without
> having to find the last sentence they read.

I don't think you are talking about the same issue as Andreas was.
His original use case was with thumbnails, which are by definition
small images unfit for displaying any significant amounts of text
embedded in the image.

By contrast, when viewing an image generated from PDF, the image of a
standard page of a document should usually be quite tall, so it should
be easy to have pixel-wise scrolling that you describe with the
current codebase.  Moreover, what you describe above about having the
already read part scrolled out of view only makes sense when there's a
significant amount of text shown in the image, which again tells me
that you refer to tall images for which pixel-wise scrolling is
already supported by C-p/C-n and up- and down-arrows, and also by the
equivalent mouse gestures.

If the PDF viewing command wants to support this feature for images
smaller than the window height, it could display the image in slices,
I think.  Emacs already supports such display.  If a screen line holds
only a portion of an image, then it should be possible to scroll only
that portion with the current display code.

> The UI gesture for such reading mode is either mouse scrolling or
> pressing the <down> arrow repeatedly or continuously. In both cases,
> the reader wants scrolling to be as smooth as possible, ideally, with
> each press or each wheel step scrolling by a constant number of
> pixels. (Mouse scrolling may be further improved with acceleration,
> but also based on pixels, not logical lines.)

Smooth pixel-wise scrolling of arbitrary stuff on display should be
possible, as the infrastructure for that already exists in the form of
a window's vscroll value.  However, supporting this consistently on
the user level will require non-trivial changes in the part of the
display engine that decides how much to scroll, because currently that
part is heavily biased towards avoiding partial screen lines whenever
possible.  This bias exists both on the C level and on the Lisp level
(see line-move and line-move-partial, for example, which are the
workhorses of visual line movement we use all the time).  Moreover,
this bias is heavier when the screen line in question includes point.

The reason for this bias is clear: the display engine was designed and
implemented primarily for showing variable-size text with only a few
images; if that assumption is invalidated, many design and
implementation decisions will be invalid as well.