Subject: bug#69992: Minor improvement to image map transformation logic

From: Joseph Turner <[email-masked]>
Date: Wed, 27 Mar 2024 15:17:31 -0700

David Ponce <[email-masked]> writes:

> On 27/03/2024 13:50, Eli Zaretskii wrote:
>>> Date: Wed, 27 Mar 2024 12:16:11 +0100
>>> From:  David Ponce via "Bug reports for GNU Emacs,
>>>   the Swiss army knife of text editors" <[email-masked]>
>>>
>>> Many thanks for this feature, which is particularly useful to
>>> automatically recalculate the map of computed images like SVG.

You're welcome!

>>> To make the code faster, by avoiding multiple scans of the map for
>>> copy and parsing, I propose the following patch which factors most of
>>> the code into the functions `image--compute-map' and `image--compute
>>> -original-map'. I have done some tests on my side which are
>>> conclusive.

Thanks for reviewing and optimizing this feature.  Please share the
tests/benchmarks that you've performed.

>>> Furthermore, I wonder if the term :base-map would not be more
>>> descriptive than :original-map?

I am fine with changing :original-map to :base-map.  If you want to do
this, I suggest making this change in its own commit which also updates
the relevant docstrings and manual pages.

>> Thanks.
>> Joseph, any comments or suggestions?

On my machine, not all tests pass with the patch.  Please be sure that
these three new tests pass:

image-create-image-with-map
image--compute-map-and-original-map
image-transform-map

Personally, I find it easier to understand image map transformation when
the logic is split into multiple functions.  However, the benefit of
readability could certainly be outweighed by a noticeable improvement to
user experience.  Please share some benchmarks.

Please keep in mind that `image--delayed-change-size' already debounces
image transformation, so this code may not be so performance-critical.

Thank you,

Joseph

> Attached the same patch slightly cleaned up.
>
> [2. text/x-patch; image.el-compute-map-V1.patch]...