emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Image transformations


From: Alan Third
Subject: Re: Image transformations
Date: Fri, 28 Jun 2019 19:36:04 +0100
User-agent: Mutt/1.12.0 (2019-05-25)

On Thu, Jun 27, 2019 at 04:59:06PM +0300, Eli Zaretskii wrote:
> What I have now is below.  This doesn't yet include documentation
> changes.
> 
> I could only test this on MS-Windows, but I hope I didn't goof on
> other platforms.  I left the NS code to use the same matrix as
> XRender/Cairo, as I couldn't test the result of letting it use the
> inverted matrix like MS-Windows does.  If using that matrix works for
> NS, the inversion in nsimage.m could be removed.

I tested before and after I moved the HAVE_NS checks and removed the
inversion from nsimage.m and it all works, so I’d say you’ve done a
good job. We may as well use the same calculations for W32 and NS.

> There's a FIXME in image_set_rotation, please tell what you think
> about it.

I think you’re probably right that we should throw an error there.

> Please also comment on image-transforms-p.  Maybe we should return
> both 'rotate' and 'rotate90' in the list when ImageMagick is
> available?

Yes, we probably should. My only concern is that there is no simple
way to tell whether you should be using ‘:type imagemagick’ or not.
There’s no automatic fallback between types. I know we want fallback
in principal, but I’d imagined it done at the lisp level, and this
function doesn’t help too much.

This is why I’d been thinking about the capabilities being arranged
around image backends.

> +image_set_rotation (struct image *img, double *rotation)

Should we rename this to compute_image_rotation to mirror
compute_image_size?

> +image_set_transform (struct frame *f, struct image *img, matrix3x3 matrix)

I don’t think we need to pass this a matrix any more?

-- 
Alan Third



reply via email to

[Prev in Thread] Current Thread [Next in Thread]