:max-width/:max-height

:max-width/:max-height

[Lars Magne Ingebrigtsen]

It was probably lost in that long bickering thread about whether
lookup_image pushed stuff over X or not, but I realised that the
interface shr needs is :max-width and :max-height on images.

And I think that's the common use case, actually.  When displaying
images in Emacs, we seldom want to display images that are bigger than
the frame, because Emacs doesn't really deal with that situation
ideally.

The other advantages is that it allows us to decode the image only once,
and we don't have to cache the representation of the huge pre-scaled
image, which we won't need anyway.

So it's a win both speed-wise (hugely over X) and interface wise, I
think.

If this is acceptable, I'll whip up a patch to implement it.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: :max-width/:max-height

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 21 Jun 2013 09:40:26 +0200
> 
> It was probably lost in that long bickering thread about whether
> lookup_image pushed stuff over X or not, but I realised that the
> interface shr needs is :max-width and :max-height on images.

What would such an interface provide to its callers?

> And I think that's the common use case, actually.  When displaying
> images in Emacs, we seldom want to display images that are bigger than
> the frame, because Emacs doesn't really deal with that situation
> ideally.

I wouldn't recommend assuming that Emacs doesn't deal well with large
images.  Changes committed lately already make it deal much better
with vertical scrolling, and doing the same for horizontal scrolling
should be easy.

So my recommendation would be not to base development on this
assumption.

The user might legitimately want not to download large images, but for
that, we already have max-image-size and check_image_size, no?

Re: :max-width/:max-height

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> It was probably lost in that long bickering thread about whether
>> lookup_image pushed stuff over X or not, but I realised that the
>> interface shr needs is :max-width and :max-height on images.
>
> What would such an interface provide to its callers?

I'm not sure I understand the question.  It would allow scaling the
images to fit in a window without having to do the tedious computations
in the caller, and it would require decoding the image only once.

> I wouldn't recommend assuming that Emacs doesn't deal well with large
> images.  Changes committed lately already make it deal much better
> with vertical scrolling, and doing the same for horizontal scrolling
> should be easy.

You've made it much better lately, but it's still awkward.  However,
that's not the main point.  When you ask Emacs to display an image, you
usually don't want to see a section of the image -- you want to see the
entire thing.  This is what Firefox does, for instance, if you ask it to
display a single image that is too large for its window.

shr has functions for zooming in the scaled image afterwards, if you
really want to see the details, of course.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: :max-width/:max-height

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 21 Jun 2013 12:08:40 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> It was probably lost in that long bickering thread about whether
> >> lookup_image pushed stuff over X or not, but I realised that the
> >> interface shr needs is :max-width and :max-height on images.
> >
> > What would such an interface provide to its callers?
> 
> I'm not sure I understand the question.  It would allow scaling the
> images to fit in a window without having to do the tedious computations
> in the caller, and it would require decoding the image only once.

Can you show a pseudo-code that would illustrate the idea?

Re: :max-width/:max-height

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you show a pseudo-code that would illustrate the idea?

(put-image (create-image "/tmp/foo.png" nil nil
            :max-width (frame-width)
            :max-height (frame-height)))

The tedious bit about the computation is finding out whether to use the
max-width or the max-height when computing the width and height to use.
(We want to keep the aspect ratio.)
            
-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: :max-width/:max-height

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 21 Jun 2013 12:29:05 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can you show a pseudo-code that would illustrate the idea?
> 
> (put-image (create-image "/tmp/foo.png" nil nil
>             :max-width (frame-width)
>             :max-height (frame-height)))
> 
> The tedious bit about the computation is finding out whether to use the
> max-width or the max-height when computing the width and height to use.
> (We want to keep the aspect ratio.)

So it's about hiding these computations behind an API, rather than
doing them on the application level, is that right?

Re: :max-width/:max-height

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So it's about hiding these computations behind an API, rather than
> doing them on the application level, is that right?

And the speed-up.  If the X pushing thing is fixed, then the latter
wouldn't be much of an issue, but :max-width/:max-height is still a very
convenient thing to have.

I've now implemented it and pushed it.  I think I managed to get all the
various possible combinations of specifying
:width/:height/:max-width/:max-height right, but I wouldn't bet on it.
Much.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/