From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Image transformations Date: Wed, 26 Jun 2019 18:34:00 +0300 Message-ID: <83r27gjr87.fsf@gnu.org> References: <20190613165804.GB11266@breton.holly.idiocy.org> <83d0jhz9za.fsf@gnu.org> <20190613192724.GA11945@breton.holly.idiocy.org> <83zhmlxo6d.fsf@gnu.org> <20190613222626.GA12971@breton.holly.idiocy.org> <83o930y7cl.fsf@gnu.org> <20190615104242.GA13368@breton.holly.idiocy.org> <838su3w0de.fsf@gnu.org> <20190616152259.GA22789@breton.holly.idiocy.org> <83d0jdv68i.fsf@gnu.org> <20190617211332.GA55597@breton.holly.idiocy.org> <83a7e6na26.fsf@gnu.org> <8336jymm0g.fsf@gnu.org> <95554A73-A5B5-4407-A5B4-4F901FF5E6CF@gnu.org> <83sgrxllt1.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="247225"; mail-complaints-to="usenet@blaine.gmane.org" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 26 17:38:24 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.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hgA08-0012CG-CK for ged-emacs-devel@m.gmane.org; Wed, 26 Jun 2019 17:38:24 +0200 Original-Received: from localhost ([::1]:41282 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgA07-0005xt-D7 for ged-emacs-devel@m.gmane.org; Wed, 26 Jun 2019 11:38:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45308) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hg9wI-0005AM-LC for emacs-devel@gnu.org; Wed, 26 Jun 2019 11:34:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hg9wE-0003R3-Cq; Wed, 26 Jun 2019 11:34:23 -0400 Original-Received: from [176.228.60.248] (port=3813 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hg9w9-0007x7-GJ; Wed, 26 Jun 2019 11:34:20 -0400 In-reply-to: (message from YAMAMOTO Mitsuharu on Wed, 26 Jun 2019 09:28:17 +0900) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:238164 Archived-At: > Date: Wed, 26 Jun 2019 09:28:17 +0900 > From: YAMAMOTO Mitsuharu > Cc: Stefan Monnier , > emacs-devel@gnu.org > > First, I couldn't find any Windows GDI API that deals with affine > transformation matrices directly. The GDI API which uses the matrices directly is SetWorldTransform, see https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/nf-wingdi-setworldtransform I eventually decided not to use it, because when I tried, it displayed a slightly stretched image even with a trivial matrix, i.e. no transform at all. Also, the more general description of the topic, which you can find here: https://docs.microsoft.com/en-us/windows/desktop/gdi/about-coordinate-spaces-and-transformations and the examples here: https://docs.microsoft.com/en-us/windows/desktop/gdi/using-coordinate-spaces-and-transformations did not tell enough detail nor show enough examples for me to be sure I really understand the subject. So I'm using PlgBlt instead. But I still want to keep compatibility with the transform matrices as defined in the documentation of SetWorldTransform, and I'm using the equations shown there to produce the coordinates that PlgBlt needs. This will allow to use SetWorldTransform in the future if we want to (assuming someone will understand why it didn't work for me to be gin with). > Guessing from its API design, I think GDI does not internally perform > any (real-valued) matrix calculations, but uses some variant of > Bresenham's line algorithm for image transformations to prefer integer > arithmetics. I think the fact that SetWorldTransform exists contradicts this conclusion. The matrix is defined as an array of floats.