Displaying scrollable images in a grid-layout

Displaying scrollable images in a grid-layout

[Andreas Politz]

Hi,

I'm trying to display a bunch of images in a grid layout, in a
way that let's me scroll the window over these images, i.e. with
some displayed only partially at the bottom and/or top.

Though I couldn't figure out a way of doing it properly, so I'm
asking here.  The same problems I'm running into can be observed
with the image-dired.el package.

    (with-current-buffer (find-file-noselect
			  (expand-file-name
			   "images"
			   data-directory))
      (dired-unmark-all-marks)
      (dired-mark-directories nil)
      (dired-toggle-marks)
      (image-dired-display-thumbs)
      (setq-local scroll-conservatively 0)
      (setq-local scroll-step 0)
      (setq-local scroll-up-aggressively nil))

This should create a *image-dired* buffer.  But trying to scroll
it seems to have no effect:

    (set-window-vscroll nil (+ (window-vscroll) 1))

Setting either scroll-step or scroll-conservatively to 1 or
scroll-up-aggressively to 0.0 allows for scrolling to happen

    (setq-local scroll-step 1)
    (set-window-vscroll nil (+ (window-vscroll) 1))

But it slows down redisplay considerably, to a point where it
becomes unusable.

Is there a way of doing this ?

-ap

Re: Displaying scrollable images in a grid-layout

[Eli Zaretskii]

> From: Andreas Politz <politza@hochschule-trier.de>
> Date: Mon, 13 Apr 2015 10:06:57 +0200
> 
> I'm trying to display a bunch of images in a grid layout, in a
> way that let's me scroll the window over these images, i.e. with
> some displayed only partially at the bottom and/or top.
> 
> Though I couldn't figure out a way of doing it properly, so I'm
> asking here.  The same problems I'm running into can be observed
> with the image-dired.el package.
> 
>     (with-current-buffer (find-file-noselect
> 			  (expand-file-name
> 			   "images"
> 			   data-directory))
>       (dired-unmark-all-marks)
>       (dired-mark-directories nil)
>       (dired-toggle-marks)
>       (image-dired-display-thumbs)
>       (setq-local scroll-conservatively 0)
>       (setq-local scroll-step 0)
>       (setq-local scroll-up-aggressively nil))
> 
> This should create a *image-dired* buffer.  But trying to scroll
> it seems to have no effect:
> 
>     (set-window-vscroll nil (+ (window-vscroll) 1))

I cannot try your recipe, because image-dired-display-thumbs requires
Imagemagick to be installed, which I don't have.  If you can simulate
the same with just a bunch of image files, please show such a recipe,
and I will certainly try looking into it.

That being said, I think you are missing the PIXELWISE-P argument of
both window-vscroll and set-window-vscroll.  Aren't you?  If not,
please elaborate on what kind of partial scrolling did you want to
see.

>     (setq-local scroll-step 1)
>     (set-window-vscroll nil (+ (window-vscroll) 1))
> 
> But it slows down redisplay considerably, to a point where it
> becomes unusable.

And there's one more thing that confuses me in this statement: partial
pixel-wise scrolling will always be slow, so I'm not sure what exactly
you expected to happen.  Probably again it goes back to the fact that
I'm not sure what you were trying to accomplish, or why.

Re: Displaying scrollable images in a grid-layout

[Andreas Politz]

Eli Zaretskii <eliz@gnu.org> writes:

> I cannot try your recipe [...]

Try this:

     (defun show-data-dir-images (&optional ncolumns)
       (interactive (list 4))
       (let* ((files (directory-files
                      (expand-file-name "images" data-directory)
                      no-dot-files))
              (column 0))
         (with-current-buffer (get-buffer-create "*images*")
           (erase-buffer)
           (save-excursion
             (dolist (f files)
               (when (and (file-regular-p f)
                          (file-name-extension f)
                          (image-type-available-p
                           (intern (downcase (file-name-extension f)))))
                 (insert-image (create-image f))
                 (when (= (cl-incf column) ncolumns)
                   (insert ?\n)
                   (setq column 0)))))          
           (setq-local scroll-conservatively 0)
           (setq-local scroll-step 0)
           (setq-local scroll-up-aggressively nil)
           (display-buffer (current-buffer)))))

> That being said, I think you are missing the PIXELWISE-P argument of
> both window-vscroll and set-window-vscroll.  Aren't you?  

No both versions do nothing with above scroll settings for any argument
I've tried (unless the window is smaller than the first displayed
image).

> If not, please elaborate on what kind of partial scrolling did you
> want to see.
>

doc-view let's you scroll the page, i.e. the image is only partially
visible.  I want the same behaviour for more than one image in the
buffer. Possible display state with 2 images:

           ................
           .              .  Image 1
           .              .         
          +.--------------.+        
          |.              .|        
          |.              .| Window 
          |.              .|        
          |................|        
          |................|        
          |.              .|        
          |.              .|        
          +.--------------.+        
           .              .         
           .              .  Image 2
           .              .         
           ................         

But:

(set-window-vscroll nil 10) => Nothing happens.
(set-window-vscroll nil 99) => Nothing happens.
(set-window-vscroll nil 100 t) => Nothing.

(setq-local scroll-step 1)
(set-window-vscroll nil 10) => Scrolls, but:

Redisplay performance (or something else) greatly suffers, i.e. opening
e.g. the M-x prompt after I have executed the above 2 commands takes
about one second.  (I have tested this with emacs-git -Q .)

>> But it slows down redisplay considerably, to a point where it
>> becomes unusable.
>
> And there's one more thing that confuses me in this statement: partial
> pixel-wise scrolling will always be slow,

Not like that.

> so I'm not sure what exactly you expected to happen.  Probably again
> it goes back to the fact that I'm not sure what you were trying to
> accomplish, or why.

See above.  

Thanks for your answer.

-ap

Re: Displaying scrollable images in a grid-layout

[Eli Zaretskii]

> From: Andreas Politz <politza@hochschule-trier.de>
> Date: Mon, 13 Apr 2015 21:35:40 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I cannot try your recipe [...]
> 
> Try this:

Thanks, will do later.

> > That being said, I think you are missing the PIXELWISE-P argument of
> > both window-vscroll and set-window-vscroll.  Aren't you?  
> 
> No both versions do nothing with above scroll settings for any argument
> I've tried (unless the window is smaller than the first displayed
> image).
> 
> > If not, please elaborate on what kind of partial scrolling did you
> > want to see.
> >
> 
> doc-view let's you scroll the page, i.e. the image is only partially
> visible.  I want the same behaviour for more than one image in the
> buffer. Possible display state with 2 images:

If each image is taller than the window, a simple down-arrow should do
what you want.  (Isn't that what you see in doc-view?)  If the images
are smaller than the window height, why is such scrolling useful?
Emacs tries very hard not to show partial characters and images; what
you are trying to do works against the very design of redisplay, so it
seems.  What's the rationale?

> (set-window-vscroll nil 10) => Nothing happens.
> (set-window-vscroll nil 99) => Nothing happens.
> (set-window-vscroll nil 100 t) => Nothing.

What is the height of the image?  If it's smaller than these offsets,
Emacs won't let you do that, because you are trying to move point out
of the visible portion of the window.

P.S.  Please don't remove the list from the addressees, I don't think
we should make this a private off-list discussion.  Thanks.

Re: Displaying scrollable images in a grid-layout

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> doc-view let's you scroll the page, i.e. the image is only partially
>> visible.  I want the same behaviour for more than one image in the
>> buffer. Possible display state with 2 images:
>
> If each image is taller than the window, a simple down-arrow should do
> what you want.  (Isn't that what you see in doc-view?)

In doc-view, there is always exactly one image in the buffer.  As soon
as you've scrolled enough to its top/bottom, it'll be replaced with the
image of the next/previous page.

What Andreas wants to accomplish is to have all images of all pages of a
document in the current buffer at the same time.

Bye,
Tassilo

Re: Displaying scrollable images in a grid-layout

[Stefan Monnier]

> What Andreas wants to accomplish is to have all images of all pages of a
> document in the current buffer at the same time.

And is indeed something I'd like to see added to doc-view-mode (of
course, only when doc-view-continuous is set).


        Stefan

Re: Displaying scrollable images in a grid-layout

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What Andreas wants to accomplish is to have all images of all pages
>> of a document in the current buffer at the same time.
>
> And is indeed something I'd like to see added to doc-view-mode (of
> course, only when doc-view-continuous is set).

I suppose when Andreas says "doc-view" he actually means his own "PDF
Tools" viewer [1].  But I think the code of the feature we're talking
about is almost identical here and there, so should be easy to
transplant.

Bye,
Tassilo
[1] https://github.com/politza/pdf-tools

Re: Displaying scrollable images in a grid-layout

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Andreas Politz <politza@hochschule-trier.de>,  emacs-devel@gnu.org
> Date: Tue, 14 Apr 2015 15:29:26 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> doc-view let's you scroll the page, i.e. the image is only partially
> >> visible.  I want the same behaviour for more than one image in the
> >> buffer. Possible display state with 2 images:
> >
> > If each image is taller than the window, a simple down-arrow should do
> > what you want.  (Isn't that what you see in doc-view?)
> 
> In doc-view, there is always exactly one image in the buffer.  As soon
> as you've scrolled enough to its top/bottom, it'll be replaced with the
> image of the next/previous page.
> 
> What Andreas wants to accomplish is to have all images of all pages of a
> document in the current buffer at the same time.

I understand, but the number of images is not the issue here.  The
issue is the height of an individual image (or, if there are several
images on a single line, the tallest image on that line) in comparison
to the window height.  If the image is taller, Emacs scrolls
pixel-wise by default, because otherwise the user stands no chance of
viewing all parts of the image.

But if the window is taller than the image, Emacs tries to show the
image in its entirety, and scrolling pixel-wise in this situation
causes partial visibility, which goes against this policy.

Re: Displaying scrollable images in a grid-layout

[Eli Zaretskii]

> Date: Mon, 13 Apr 2015 23:27:52 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Try this:
> 
>      (defun show-data-dir-images (&optional ncolumns)
>        (interactive (list 4))
>        (let* ((files (directory-files
>                       (expand-file-name "images" data-directory)
>                       no-dot-files))
>               (column 0))
>          (with-current-buffer (get-buffer-create "*images*")
>            (erase-buffer)
>            (save-excursion
>              (dolist (f files)
>                (when (and (file-regular-p f)
>                           (file-name-extension f)
>                           (image-type-available-p
>                            (intern (downcase (file-name-extension f)))))
>                  (insert-image (create-image f))
>                  (when (= (cl-incf column) ncolumns)
>                    (insert ?\n)
>                    (setq column 0)))))          
>            (setq-local scroll-conservatively 0)
>            (setq-local scroll-step 0)
>            (setq-local scroll-up-aggressively nil)
>            (display-buffer (current-buffer)))))

After running this function, this works for me:

   (set-window-vscroll nil N t)

as long as (a) point is not on the first screen line shown in the
window, and (b) N is no more than 24, which AFAICS is the pixel size
of the small images created by the above function.

This also works:

   (set-window-vscroll nil N)

as long as N is less than the vertical coordinate of point's line in
canonical line height units.

Is that what you see?  If you see something else, we are not talking
about the same issue.

> (setq-local scroll-step 1)
> (set-window-vscroll nil 10) => Scrolls, but:
> 
> Redisplay performance (or something else) greatly suffers, i.e. opening
> e.g. the M-x prompt after I have executed the above 2 commands takes
> about one second.  (I have tested this with emacs-git -Q .)

I don't see this performance hit.  After typing "M-x", I see the
prompt with no perceptible delay, certainly nowhere near 1 sec.  So
some other factor is at work here.  Maybe your original recipe is
somehow different in this respect from the modified one, which I
tried, e.g. the thumbnail images are probably smaller, though I don't
see why that would make redisplay slower.  (I also tried to use more
than 4 columns, but saw no redisplay slow-down in that case, either.)

The other points I made in my previous message and today still hold:
there are limits to what Emacs will currently let you do with
window-vscroll, mainly due to 2 factors:

  . the basic desire embedded in redisplay to avoid showing partial
    lines, unless they are unavoidable

  . the automatic scrolling when point goes off the window

Let me know if you need further help or have additional
questions/issues about this.

Re: Displaying scrollable images in a grid-layout

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> In doc-view, there is always exactly one image in the buffer.  As
>> soon as you've scrolled enough to its top/bottom, it'll be replaced
>> with the image of the next/previous page.
>> 
>> What Andreas wants to accomplish is to have all images of all pages
>> of a document in the current buffer at the same time.
>
> I understand, but the number of images is not the issue here.  The
> issue is the height of an individual image (or, if there are several
> images on a single line, the tallest image on that line) in comparison
> to the window height.  If the image is taller, Emacs scrolls
> pixel-wise by default, because otherwise the user stands no chance of
> viewing all parts of the image.
>
> But if the window is taller than the image, Emacs tries to show the
> image in its entirety, and scrolling pixel-wise in this situation
> causes partial visibility, which goes against this policy.

For such a mode, it should not matter if the window is taller than the
image or if it is the other way round.  You always want pixel-wise
scrolling.

Bye,
Tassilo

Re: Displaying scrollable images in a grid-layout

[Andreas Politz]

Eli Zaretskii <eliz@gnu.org> writes:

>> Try this:
>> 
>>      (defun show-data-dir-images (&optional ncolumns)
>> [...]

> After running this function, this works for me:
>
>    (set-window-vscroll nil N t)
>
> as long as (a) point is not on the first screen line shown in the
> window, and (b) N is no more than 24, which AFAICS is the pixel size
> of the small images created by the above function.

Yes but the whole point is to display only half of an image at the top.
This recipe is not ideal. In the real application I would have 2 images
(pages of a PDF) side by side, filling e.g 3/4 of the windows vertical
space.  Below these images are another 2 which are only 1/4-way visible.
Now I want to scroll these 4 images up by let's say the equivalent of
next-screen-context-lines in pixels.

Would this be a feature supported by Emacs ?

>> (setq-local scroll-step 1)
>> (set-window-vscroll nil 10) => Scrolls, but:
>> 
>> Redisplay performance (or something else) greatly suffers,[...]
>
> I don't see this performance hit.  [...]

I am not able to reproduce it either just now...

> The other points I made in my previous message and today still hold:
> there are limits to what Emacs will currently let you do with
> window-vscroll, mainly due to 2 factors:
>
>   . the basic desire embedded in redisplay to avoid showing partial
>     lines, unless they are unavoidable
>
>   . the automatic scrolling when point goes off the window
>
> Let me know if you need further help or have additional
> questions/issues about this.

Thank you.

-ap

Re: Displaying scrollable images in a grid-layout

[Stefan Monnier]

> I suppose when Andreas says "doc-view" he actually means his own "PDF
> Tools" viewer [1].

Reminds me: I'd be happy to see that package in GNU ELPA.  AFAICT all
4 contributors mentioned in the Git log have already signed the needed
paperwork, so the road is clear.


        Stefan

Re: Displaying scrollable images in a grid-layout

[Rasmus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I suppose when Andreas says "doc-view" he actually means his own "PDF
>> Tools" viewer [1].
>
> Reminds me: I'd be happy to see that package in GNU ELPA.  AFAICT all
> 4 contributors mentioned in the Git log have already signed the needed
> paperwork, so the road is clear.

+∞ 

I would like to see it in core.  It's the best pdf-viewer on GNU/Linux
(including the ones not running in Emacs).  I don't know if it runs on
other platforms.

—Rasmus

-- 
Hvor meget poesi tror De kommer ud af et glas isvand?

Re: Displaying scrollable images in a grid-layout

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: politza@hochschule-trier.de,  emacs-devel@gnu.org
> Date: Tue, 14 Apr 2015 21:24:38 +0200
> 
> > But if the window is taller than the image, Emacs tries to show the
> > image in its entirety, and scrolling pixel-wise in this situation
> > causes partial visibility, which goes against this policy.
> 
> For such a mode, it should not matter if the window is taller than the
> image or if it is the other way round.  You always want pixel-wise
> scrolling.

??? Why does it make sense to show a partial line, when we can show it
in its entirety?  Can you explain?

Re: Displaying scrollable images in a grid-layout

[Eli Zaretskii]

> From: Andreas Politz <politza@hochschule-trier.de>
> Date: Tue, 14 Apr 2015 21:29:04 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Try this:
> >> 
> >>      (defun show-data-dir-images (&optional ncolumns)
> >> [...]
> 
> > After running this function, this works for me:
> >
> >    (set-window-vscroll nil N t)
> >
> > as long as (a) point is not on the first screen line shown in the
> > window, and (b) N is no more than 24, which AFAICS is the pixel size
> > of the small images created by the above function.
> 
> Yes but the whole point is to display only half of an image at the top.

Like I said: it works for me under the conditions described above.

> This recipe is not ideal. In the real application I would have 2 images
> (pages of a PDF) side by side, filling e.g 3/4 of the windows vertical
> space.  Below these images are another 2 which are only 1/4-way visible.
> Now I want to scroll these 4 images up by let's say the equivalent of
> next-screen-context-lines in pixels.

Can you explain why such a partial scroll is a good idea?  We can show
the entire line, and yet you want us to show only part of it?

> Would this be a feature supported by Emacs ?

Like I said, it goes against the current redisplay strategy to show
full lines whenever possible.  So it would be possible to support that
under some option, but it would need a lot of non-trivial changes.

Re: Displaying scrollable images in a grid-layout

[Yuri Khan]

On Wed, Apr 15, 2015 at 8:37 AM, Eli Zaretskii <eliz@gnu.org> wrote:

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

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.

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

Re: Displaying scrollable images in a grid-layout

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Wed, 15 Apr 2015 10:17:02 +0600
> Cc: Tassilo Horn <tsdh@gnu.org>, politza@hochschule-trier.de, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > ??? 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.

Re: Displaying scrollable images in a grid-layout

[Yuri Khan]

On Wed, Apr 15, 2015 at 10:05 PM, Eli Zaretskii <eliz@gnu.org> wrote:

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

Right, I somehow missed the part about thumbnails.

I personally don’t see page thumbnails as a useful feature; for me,
pages of text at thumbnail size are not distinctive enough to be able
to choose between them. Therefore, I cannot clearly reason about their
scroll behavior.

However, I believe the threshold where pixel-based scrolling and
glyph-row-based scrolling meet should be when at least two full glyph
rows fit in a window; this way, after the scroll, the previous row is
still visible, providing some continuity.

Re: Displaying scrollable images in a grid-layout

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Wed, 15 Apr 2015 22:35:48 +0600
> Cc: Tassilo Horn <tsdh@gnu.org>, politza@hochschule-trier.de, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> However, I believe the threshold where pixel-based scrolling and
> glyph-row-based scrolling meet should be when at least two full glyph
> rows fit in a window; this way, after the scroll, the previous row is
> still visible, providing some continuity.

If you really meant "at least", then this means no threshold at all,
because obviously we have to, and already do, provide pixel-based
scrolling when a glyph row does NOT fit in the window.  Right?

Re: Displaying scrollable images in a grid-layout

[Yuri Khan]

On Wed, Apr 15, 2015 at 10:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> However, I believe the threshold where pixel-based scrolling and
>> glyph-row-based scrolling meet should be when at least two full glyph
>> rows fit in a window; this way, after the scroll, the previous row is
>> still visible, providing some continuity.
>
> If you really meant "at least", then this means no threshold at all,
> because obviously we have to, and already do, provide pixel-based
> scrolling when a glyph row does NOT fit in the window.  Right?

When a glyph row does not fit in the window: pixel-based scrolling.

When between one and two glyph rows fit: pixel-based scrolling,
because otherwise the previous row would disappear without a visual
indication where it went.

When more than two full glyph rows fit, that’s where row-based
scrolling stops being disorienting for me.

When fifty glyph rows fit the window, there is no practical difference
between pixel-based and row-based scrolling in terms of visual
feedback.

“No threshold at all” and “pixel-based scrolling when a row does not
fit” would imply pixel-based scrolling always, without regard to rows.
(Most graphical web browsers do exactly that, and I have no problems
with that; but, as you said, that would be a big change to the overall
design.)

Re: Displaying scrollable images in a grid-layout

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Wed, 15 Apr 2015 23:02:00 +0600
> Cc: Tassilo Horn <tsdh@gnu.org>, politza@hochschule-trier.de, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Wed, Apr 15, 2015 at 10:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> However, I believe the threshold where pixel-based scrolling and
> >> glyph-row-based scrolling meet should be when at least two full glyph
> >> rows fit in a window; this way, after the scroll, the previous row is
> >> still visible, providing some continuity.
> >
> > If you really meant "at least", then this means no threshold at all,
> > because obviously we have to, and already do, provide pixel-based
> > scrolling when a glyph row does NOT fit in the window.  Right?
> 
> When a glyph row does not fit in the window: pixel-based scrolling.
> 
> When between one and two glyph rows fit: pixel-based scrolling,
> because otherwise the previous row would disappear without a visual
> indication where it went.
> 
> When more than two full glyph rows fit, that’s where row-based
> scrolling stops being disorienting for me.

I guess I misunderstood what you meant by "meet".  Sorry about that.

Anyway, where they meet is definitely a matter of taste.  I see no
problem with scrolling the previous row completely out of view,
because it was fully visible before the scroll.

Re: Displaying scrollable images in a grid-layout

[Andreas Politz]

Eli Zaretskii <eliz@gnu.org> writes:

> Anyway, where they meet is definitely a matter of taste.  I see no
> problem with scrolling the previous row completely out of view,
> because it was fully visible before the scroll.

Or leave the space blank. Both options would work, but are not like
other programs operate in these case, e.g evince in
dual-page+continuous-mode.

Anyway, I'm just considering my options.

-ap

Re: Displaying scrollable images in a grid-layout

[Stefan Monnier]

> Anyway, where they meet is definitely a matter of taste.  I see no
> problem with scrolling the previous row completely out of view,
> because it was fully visible before the scroll.

FWIW, I think I tend to have similar tastes to Yuri in this case: when
scrolling by just one line ends up scrolling by more than half the
window's size, I'd prefer to fallback on pixel-based scrolling.


        Stefan