unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Image transforms as a benchmark?
@ 2021-09-12 11:45 Arthur Miller
  2021-09-12 12:12 ` Alan Third
  2021-09-12 12:17 ` Eli Zaretskii
  0 siblings, 2 replies; 7+ messages in thread
From: Arthur Miller @ 2021-09-12 11:45 UTC (permalink / raw)
  To: emacs-devel


I tried to make another little benchmark, I saw with optimization flags, that
quite some loops have got unrolled and vectorized in image.c, so I wanted to see
if it matters when doing some transforms on images. I tested so far just with
svg.

I wonder if image-rotate is handled completely by external libraries? I see
no effect on performance, regardless of how many time I rotate some image. Is it
same situation for scaling down? I see big difference when scaling up images so
I guess that is handled by Emacs own code?

#+begin_src emacs-lisp
(require 'svg)

(defun svg-position (image)
  "Return buffer position of the svg image."
  (let ((marker (cdr (assoc :image (car-safe (cdr image))))))
    (when (markerp marker)
      (marker-position marker))))

(defun svg-image-rotate (svg &optional angle)
  (let ((image (image--get-image (svg-position svg))))
    (setf (image-property image :rotation)
          (float (mod (+ (or (image-property image :rotation) 0)
                         (or angle 90))
                      360)))))

(defun svg-increase-size ()
  (with-temp-buffer
    (let ((svg (svg-create 10 10))
          (max-image-size t))
      (svg-rectangle svg 0 0 10 10)
      (svg-insert-image svg)
      (dotimes (_ 40)
      ;; use internal image--change-size
      ;; to bypass the optimization with idle-timer.
        (image--change-size
         (1+ (/ (prefix-numeric-value 2) 10.0))
         (svg-position svg))))))

(defun svg-decrease-size ()
  (with-temp-buffer
    (let ((svg (svg-create 10 10)))
      (svg-rectangle svg 0 0 10 10)
      (svg-insert-image svg)
      (dotimes (_ 20)
        (image--change-size
         (- 1 (/ (prefix-numeric-value 0.1) 10.0))
         (svg-position svg))))))
#+end_src



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Image transforms as a benchmark?
  2021-09-12 11:45 Image transforms as a benchmark? Arthur Miller
@ 2021-09-12 12:12 ` Alan Third
  2021-09-12 13:28   ` Arthur Miller
  2021-09-12 12:17 ` Eli Zaretskii
  1 sibling, 1 reply; 7+ messages in thread
From: Alan Third @ 2021-09-12 12:12 UTC (permalink / raw)
  To: Arthur Miller; +Cc: emacs-devel

On Sun, Sep 12, 2021 at 01:45:39PM +0200, Arthur Miller wrote:
> 
> I tried to make another little benchmark, I saw with optimization flags, that
> quite some loops have got unrolled and vectorized in image.c, so I wanted to see
> if it matters when doing some transforms on images. I tested so far just with
> svg.
> 
> I wonder if image-rotate is handled completely by external libraries? I see
> no effect on performance, regardless of how many time I rotate some image. Is it
> same situation for scaling down? I see big difference when scaling up images so
> I guess that is handled by Emacs own code?

SVG is probably not a great example for testing image transforms, at
least if you're using the master branch.

Image scaling in SVG is handled at the time the image is rasterized,
so if you ask for the image to be doubled in size, the rasterizer
creates a bitmap that is twice the size.

A PNG, for example, is not scaled in this way. When we ask the
graphics toolkit to draw it, we ask for to draw it at twice the size.
Ideally this should be done in the graphics hardware, so Emacs only
ever handles the unscaled image data.

The same holds for rotation for both SVG and bitmap formats. The
toolkit is asked to perform the final rotation, ideally in hardware.

I say toolkit, but in X it's actually the X server itself we ask
through XRender, which as described above should hand that off to the
graphics hardware.

I'm unsure what loops might be unrolled within image.c, I'd guess it's
probably loops relating to creating images and image masks.

You could perhaps try stepping through the frames of an animated GIF.
Our rendering algorithm is rather... inefficient.
-- 
Alan Third



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Image transforms as a benchmark?
  2021-09-12 11:45 Image transforms as a benchmark? Arthur Miller
  2021-09-12 12:12 ` Alan Third
@ 2021-09-12 12:17 ` Eli Zaretskii
  2021-09-12 13:29   ` Arthur Miller
  1 sibling, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2021-09-12 12:17 UTC (permalink / raw)
  To: Arthur Miller, Alan Third; +Cc: emacs-devel

> From: Arthur Miller <arthur.miller@live.com>
> Date: Sun, 12 Sep 2021 13:45:39 +0200
> 
> I wonder if image-rotate is handled completely by external libraries? I see
> no effect on performance, regardless of how many time I rotate some image.

It's handled by the window-system libraries: XLib or Cairo or
ImageMagick on Unix, GDI on Windows, etc.  So you shouldn't see any
significant performance changes in these functionalities due to
optimization switches.

> Is it same situation for scaling down? I see big difference when
> scaling up images so I guess that is handled by Emacs own code?

Not sure (is your build with or without ImageMagick?), but perhaps
Alan does.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Image transforms as a benchmark?
  2021-09-12 12:12 ` Alan Third
@ 2021-09-12 13:28   ` Arthur Miller
  2021-09-12 15:50     ` Alan Third
  0 siblings, 1 reply; 7+ messages in thread
From: Arthur Miller @ 2021-09-12 13:28 UTC (permalink / raw)
  To: Alan Third; +Cc: emacs-devel

Alan Third <alan@idiocy.org> writes:

> On Sun, Sep 12, 2021 at 01:45:39PM +0200, Arthur Miller wrote:
>> 
>> I tried to make another little benchmark, I saw with optimization flags, that
>> quite some loops have got unrolled and vectorized in image.c, so I wanted to see
>> if it matters when doing some transforms on images. I tested so far just with
>> svg.
>> 
>> I wonder if image-rotate is handled completely by external libraries? I see
>> no effect on performance, regardless of how many time I rotate some image. Is it
>> same situation for scaling down? I see big difference when scaling up images so
>> I guess that is handled by Emacs own code?
>
> SVG is probably not a great example for testing image transforms, at
> least if you're using the master branch.

I wanted to make few benchmarks that are relevant to normal use. I do some
searches, replacements and similar in a big text buffer (Plat's dialoagues as I
posted a day before), and I did some symbol lookups in Emacs lisp sources. SVG
is getting a bit of uprise lately, so thought it might matter. But I'll guess
I'll skip SVG then.

> Image scaling in SVG is handled at the time the image is rasterized,
> so if you ask for the image to be doubled in size, the rasterizer
> creates a bitmap that is twice the size.

Yes, I saw the code. But I wasn't sure if it does upscaling itself, or it
outsources the entire venture to librsvg & co. I understand the most of image
operations are handled by 3rd party libraries. I saw some code for image
transforms in image.c, but I haven't looked much where it is used and so, maybe
I should have :).

Why is it so drammatic difference then when scaling up compared to scaling down?
It takes like 5 seconds to do that loop in scale-up test, but just a fraction of
a second when scaling down. I tested little different versions, and I see the
effect, so scaling is done.

> A PNG, for example, is not scaled in this way. When we ask the
> graphics toolkit to draw it, we ask for to draw it at twice the size.
> Ideally this should be done in the graphics hardware, so Emacs only
> ever handles the unscaled image data.
>
> The same holds for rotation for both SVG and bitmap formats. The
> toolkit is asked to perform the final rotation, ideally in hardware.
>
> I say toolkit, but in X it's actually the X server itself we ask
> through XRender, which as described above should hand that off to the
> graphics hardware.
>
> I'm unsure what loops might be unrolled within image.c, I'd guess it's
> probably loops relating to creating images and image masks.
>
> You could perhaps try stepping through the frames of an animated GIF.
> Our rendering algorithm is rather... inefficient.

I am not sure how to write such test. I'll see, never really worked with gifs in
Emacs.


Thanks both for clarifications.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Image transforms as a benchmark?
  2021-09-12 12:17 ` Eli Zaretskii
@ 2021-09-12 13:29   ` Arthur Miller
  0 siblings, 0 replies; 7+ messages in thread
From: Arthur Miller @ 2021-09-12 13:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Alan Third, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Sun, 12 Sep 2021 13:45:39 +0200
>> 
>> I wonder if image-rotate is handled completely by external libraries? I see
>> no effect on performance, regardless of how many time I rotate some image.
>
> It's handled by the window-system libraries: XLib or Cairo or
> ImageMagick on Unix, GDI on Windows, etc.  So you shouldn't see any
> significant performance changes in these functionalities due to
> optimization switches.
Yes, I understand.

>> Is it same situation for scaling down? I see big difference when
>> scaling up images so I guess that is handled by Emacs own code?
>
> Not sure (is your build with or without ImageMagick?)

It is without ImageMagick.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Image transforms as a benchmark?
  2021-09-12 13:28   ` Arthur Miller
@ 2021-09-12 15:50     ` Alan Third
  2021-09-12 17:50       ` Arthur Miller
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Third @ 2021-09-12 15:50 UTC (permalink / raw)
  To: Arthur Miller; +Cc: emacs-devel

On Sun, Sep 12, 2021 at 03:28:09PM +0200, Arthur Miller wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > On Sun, Sep 12, 2021 at 01:45:39PM +0200, Arthur Miller wrote:
> >> 
> >> I tried to make another little benchmark, I saw with optimization flags, that
> >> quite some loops have got unrolled and vectorized in image.c, so I wanted to see
> >> if it matters when doing some transforms on images. I tested so far just with
> >> svg.
> >> 
> >> I wonder if image-rotate is handled completely by external libraries? I see
> >> no effect on performance, regardless of how many time I rotate some image. Is it
> >> same situation for scaling down? I see big difference when scaling up images so
> >> I guess that is handled by Emacs own code?
> >
> > SVG is probably not a great example for testing image transforms, at
> > least if you're using the master branch.
> 
> I wanted to make few benchmarks that are relevant to normal use. I do some
> searches, replacements and similar in a big text buffer (Plat's dialoagues as I
> posted a day before), and I did some symbol lookups in Emacs lisp sources. SVG
> is getting a bit of uprise lately, so thought it might matter. But I'll guess
> I'll skip SVG then.

Well, don't let me put you off if you're bench-marking things that
actually matter. I assumed it was a purely intellectual exercise.

> > Image scaling in SVG is handled at the time the image is rasterized,
> > so if you ask for the image to be doubled in size, the rasterizer
> > creates a bitmap that is twice the size.
> 
> Yes, I saw the code. But I wasn't sure if it does upscaling itself, or it
> outsources the entire venture to librsvg & co. I understand the most of image
> operations are handled by 3rd party libraries. I saw some code for image
> transforms in image.c, but I haven't looked much where it is used and so, maybe
> I should have :).
> 
> Why is it so drammatic difference then when scaling up compared to scaling down?
> It takes like 5 seconds to do that loop in scale-up test, but just a fraction of
> a second when scaling down. I tested little different versions, and I see the
> effect, so scaling is done.

I have no idea. Both scaling up and down are performed by librsvg
itself. It may be some side-effect of the way we do the scaling, with
the wrapped SVG, but I don't have enough knowledge of librsvg to know
why.

Alternatively we're doing something wrong that I haven't noticed.

Is it possible to use a profiler to find out which calls are slow?

> > You could perhaps try stepping through the frames of an animated GIF.
> > Our rendering algorithm is rather... inefficient.
> 
> I am not sure how to write such test. I'll see, never really worked with gifs in
> Emacs.

If it doesn't matter to you, it's probably not worth your while. We
know why it's slow (we need to cache the intermediate images).
-- 
Alan Third



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Image transforms as a benchmark?
  2021-09-12 15:50     ` Alan Third
@ 2021-09-12 17:50       ` Arthur Miller
  0 siblings, 0 replies; 7+ messages in thread
From: Arthur Miller @ 2021-09-12 17:50 UTC (permalink / raw)
  To: Alan Third; +Cc: emacs-devel

Alan Third <alan@idiocy.org> writes:

> On Sun, Sep 12, 2021 at 03:28:09PM +0200, Arthur Miller wrote:
>> Alan Third <alan@idiocy.org> writes:
>> 
>> > On Sun, Sep 12, 2021 at 01:45:39PM +0200, Arthur Miller wrote:
>> >> 
>> >> I tried to make another little benchmark, I saw with optimization flags, that
>> >> quite some loops have got unrolled and vectorized in image.c, so I wanted to see
>> >> if it matters when doing some transforms on images. I tested so far just with
>> >> svg.
>> >> 
>> >> I wonder if image-rotate is handled completely by external libraries? I see
>> >> no effect on performance, regardless of how many time I rotate some image. Is it
>> >> same situation for scaling down? I see big difference when scaling up images so
>> >> I guess that is handled by Emacs own code?
>> >
>> > SVG is probably not a great example for testing image transforms, at
>> > least if you're using the master branch.
>> 
>> I wanted to make few benchmarks that are relevant to normal use. I do some
>> searches, replacements and similar in a big text buffer (Plat's dialoagues as I
>> posted a day before), and I did some symbol lookups in Emacs lisp sources. SVG
>> is getting a bit of uprise lately, so thought it might matter. But I'll guess
>> I'll skip SVG then.
>
> Well, don't let me put you off if you're bench-marking things that
> actually matter. I assumed it was a purely intellectual exercise.
Yes, but it's no idea to measure wrong thing either :).

>> > Image scaling in SVG is handled at the time the image is rasterized,
>> > so if you ask for the image to be doubled in size, the rasterizer
>> > creates a bitmap that is twice the size.
>> 
>> Yes, I saw the code. But I wasn't sure if it does upscaling itself, or it
>> outsources the entire venture to librsvg & co. I understand the most of image
>> operations are handled by 3rd party libraries. I saw some code for image
>> transforms in image.c, but I haven't looked much where it is used and so, maybe
>> I should have :).
>> 
>> Why is it so drammatic difference then when scaling up compared to scaling down?
>> It takes like 5 seconds to do that loop in scale-up test, but just a fraction of
>> a second when scaling down. I tested little different versions, and I see the
>> effect, so scaling is done.
>
> I have no idea. Both scaling up and down are performed by librsvg
> itself. It may be some side-effect of the way we do the scaling, with
> the wrapped SVG, but I don't have enough knowledge of librsvg to know
> why.
>
> Alternatively we're doing something wrong that I haven't noticed.
>
> Is it possible to use a profiler to find out which calls are slow?
It probably is, you are correct :). I haven't tried; I should have. When I am
done with some benchmarks, I can take a peek.

Thanks for the help!



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-09-12 17:50 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-12 11:45 Image transforms as a benchmark? Arthur Miller
2021-09-12 12:12 ` Alan Third
2021-09-12 13:28   ` Arthur Miller
2021-09-12 15:50     ` Alan Third
2021-09-12 17:50       ` Arthur Miller
2021-09-12 12:17 ` Eli Zaretskii
2021-09-12 13:29   ` Arthur Miller

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).