From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Pittman Newsgroups: gmane.emacs.devel Subject: Re: Native image rotation Date: Tue, 26 Feb 2019 12:01:24 -0500 Message-ID: References: <20190224113050.GA67303@breton.holly.idiocy.org> <83tvgtnoyh.fsf@gnu.org> <20190224232228.GA67813@breton.holly.idiocy.org> <83y364mtde.fsf@gnu.org> <20190225192102.GA3060@breton.holly.idiocy.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000ffe2470582cf039a" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="118168"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Eli Zaretskii , emacs-devel To: Alan Third Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 26 18:05:38 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gygAj-000Ucc-4t for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2019 18:05:37 +0100 Original-Received: from localhost ([127.0.0.1]:58629 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gygAi-0001ug-2s for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2019 12:05:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyg7J-0000Gp-SJ for emacs-devel@gnu.org; Tue, 26 Feb 2019 12:02:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gyg7H-00044p-Mx for emacs-devel@gnu.org; Tue, 26 Feb 2019 12:02:05 -0500 Original-Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:34440) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gyg7H-000400-2T for emacs-devel@gnu.org; Tue, 26 Feb 2019 12:02:03 -0500 Original-Received: by mail-ed1-x533.google.com with SMTP id a16so11377254edn.1 for ; Tue, 26 Feb 2019 09:02:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AFXg7jwKztwuGKkVpK9Vs0hvzgrqVAOYanZ00rYPO3k=; b=WTR9zTPiEFAGRym2BwqjH16QhEJhpQTBZmvdu2QaE/hUPjoW7GjF/hS7pJAtnNkOvW Q66hZbzPMF/qMNVOSt3v0L1mShZiTtn+/kzU5ZQ0Ihnd4hcH2b/8i5eLSEKAK2JRWDY1 oqbONSlUVBaX4vcCQaBJBYzXueRAdhBuJmhrpGEzastxFOFvEdvv606JHvrfpSI98Uof yvpevJJQdebPU5/KtWV3MZ2uRMmZWKoU85ZV1phR05ntL7A5yCXiLhaFrjh91fz6fHjd 2J7tbLeEgEowUjybUC6ZE4M1DD1zOmoJXJtVh56rpvLzaXC5cUYyuj9hNrEYY+7wk1Nd D7nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AFXg7jwKztwuGKkVpK9Vs0hvzgrqVAOYanZ00rYPO3k=; b=HKoeojZgbfqe3E1HHbszRE8ZHKZSwdVsXkpn51R06gSgpaBZJ7XYp5MyPUrI0nOPq4 d6c94bxf0Mhv8E9xKOvpDSDOa1qM5vKg9/7vxVqMfgBTMYdiIe3lOLA4uziluZ04TqDx HKwP1uD3uYuJHmahgLAq1de8pzsF4GNcWp0ZVV9AqFEAa2TSkizYFdkSW/q6o9lPSjps D+yNmg0etQz7KhNKG7Ly/IzUzu5eZrPBP8gytBAmev2VpcpbjvaB9R7Br3ZmaYvW2T91 rE47pUw1N0HKArv2S2qFGzgfkBuh1+GLNabMUivZK1qey8DGo/v78NJtsgxqjBg2172h 813w== X-Gm-Message-State: AHQUAuaRgn0+F7aZndfUnbVb6acATV20KRkn7FRnmNrKVze+FvbicCuw rnReFNSRlhF7VTQxC6TC0oqYroEXRKp3FXa4l8oYHw== X-Google-Smtp-Source: AHgI3Ibc0TihfXDy9xaunJ+X/YxOprZx4xXqbaSGMNGPFzsRWsM+fAEXZ55M6G2z6Vkq4JQY6mjCOGPzEKriJtjEBfU= X-Received: by 2002:a17:906:d0c1:: with SMTP id bq1mr2213590ejb.206.1551200520457; Tue, 26 Feb 2019 09:02:00 -0800 (PST) In-Reply-To: <20190225192102.GA3060@breton.holly.idiocy.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::533 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:233639 Archived-At: --000000000000ffe2470582cf039a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As others, I'd certainly like to be able to perform arbitrary rotations. Working with photos to extract, eg, document contents from a scanned image, and displaying a graphical "busy" spinner, are the use cases I have handled before. If performance was too poor, I'd be more inclined to look at how to improve performance in Emacs than to abandon the approach in favor of a large number of barely changed images. That would, after all, make life better for everyone, and I have confidence that it *would* be possible to make that efficient enough to work. After all, I don't need 60FPS rendering of this, and that is definitely achievable for vastly more complex 2D and 3D layouts on the display layers on all the platforms Emacs supports, thanks to browsers among other tools. On Mon, Feb 25, 2019 at 2:21 PM Alan Third wrote: > On Mon, Feb 25, 2019 at 05:36:46AM +0200, Eli Zaretskii wrote: > > > Date: Sun, 24 Feb 2019 23:22:28 +0000 > > > From: Alan Third > > > Cc: emacs-devel@gnu.org > > > > > > And I guess we maybe wouldn=E2=80=99t have to worry about clearing un= der the > > > image any more in X: rotating can leave transparent sections. > > > > > > But the maths is performed only once, when the image is loaded, so I > > > doubt we=E2=80=99d find a significant improvement. > > > > It's indeed the clearing that bothered me, > > Would it be better if it was done by another XRender composite rather > than x_clear_area? > > If this really is a problem then I think we have to allow only 90 > degree multiples. I can=E2=80=99t see any other reasonable solution. > > > and also the increase in the screen estate taken by a rotated image. > > I think that would be less of an issue with the addition of cropping, > as an image could be rotated then cropped down to size. Besides, if > someone wants to rotate at 45 degrees they=E2=80=99ve got to expect the s= ize > of the image to change, there=E2=80=99s no other reasonable option. > > > I'm asking whether it's worth it. > > Limiting to 90 degree increments feels like an arbitrary limitation, > but I don=E2=80=99t feel strongly about it either way. > -- > Alan Third > > --000000000000ffe2470582cf039a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As others, I'd certainly like to be able to perform ar= bitrary rotations.=C2=A0 Working with photos to extract, eg, document conte= nts from a scanned image, and displaying a graphical "busy" spinn= er, are the use cases I have handled before.

If performa= nce was too poor, I'd be more inclined to look at how to improve perfor= mance in Emacs than to abandon the approach in favor of a large number of b= arely changed images.=C2=A0 That would, after all, make life better for eve= ryone, and I have confidence that it *would* be possible to make that effic= ient enough to work.

After all, I don't need 6= 0FPS rendering of this, and that is definitely achievable for vastly more c= omplex 2D and 3D layouts on the display layers on all the platforms Emacs s= upports, thanks to browsers among other tools.

On Mon, Feb 25, 2019 at= 2:21 PM Alan Third <alan@idiocy.org<= /a>> wrote:
O= n Mon, Feb 25, 2019 at 05:36:46AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 24 Feb 2019 23:22:28 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: emac= s-devel@gnu.org
> >
> > And I guess we maybe wouldn=E2=80=99t have to worry about clearin= g under the
> > image any more in X: rotating can leave transparent sections.
> >
> > But the maths is performed only once, when the image is loaded, s= o I
> > doubt we=E2=80=99d find a significant improvement.
>
> It's indeed the clearing that bothered me,

Would it be better if it was done by another XRender composite rather
than x_clear_area?

If this really is a problem then I think we have to allow only 90
degree multiples. I can=E2=80=99t see any other reasonable solution.

> and also the increase in the screen estate taken by a rotated image.
I think that would be less of an issue with the addition of cropping,
as an image could be rotated then cropped down to size. Besides, if
someone wants to rotate at 45 degrees they=E2=80=99ve got to expect the siz= e
of the image to change, there=E2=80=99s no other reasonable option.

> I'm asking whether it's worth it.

Limiting to 90 degree increments feels like an arbitrary limitation,
but I don=E2=80=99t feel strongly about it either way.
--
Alan Third

--000000000000ffe2470582cf039a--