bug#46556: 27.1; transparent images are displayed incorrectly if rotated

[Alan Third]

On Wed, Feb 17, 2021 at 07:26:38PM +0000, Alan Third wrote:
> On Wed, Feb 17, 2021 at 07:05:38PM +0200, Eli Zaretskii wrote:
> > > Date: Tue, 16 Feb 2021 21:24:24 +0000
> > > From: Alan Third <alan@idiocy.org>
> > > Cc: ynyaaa@gmail.com, 46556@debbugs.gnu.org
> > > 
> > > > Would it be possible for you to test with Emacs 28 and see whether the
> > > > problem you report (on Windows) is still present there?
> > > 
> > > It does sound like something must be going wrong on Windows.
> > > Unfortunately I don't know what that could be because, as I said on
> > > the other bug report, NS and Windows use the same rotation logic, and
> > > NS is fine, so it must be when it comes to actually drawing that the
> > > problem manifests.
> > 
> > I've now stepped through the code which implements rotation, and I see
> > nothing wrong with the results.  The pixel coordinates of the rotated
> > square are exact and accurate, without any roundoff that I could spot.
> > Each square starts exactly 50+8 = 58 pixels after the previous one (8
> > pixels are taken by the SPC character between the squares), and ends
> > exactly 50 pixels after it starts.
> > 
> > So I have no idea why the one-pixel shift happens.  Of course, I don't
> > really understand what that code does (although I hacked it quite
> > extensively), so maybe someone who really understands that stuff could
> > take a look and tell what's wrong there.
> 
> Can either you or the OP provide a screenshot? It's not entirely clear
> to me what's happening. It sounds like some of the behaviour of this
> bug would be explained by the mask not being rotated with the image,
> but other bits of the description don't seem to match that.
> 
> The other bug with the single pixel white line sounds more like an
> off-by-one in SVG production, but you'd see that in every image, so
> it's probably not that.

In fact, I'm just looking over w32term.c and in the function transform
there are two equations:

  pt.x =
    x0 + (x - x0) * xform->eM11 + (y - y0) * xform->eM21 + xform->eDx + 0.5f;
  pt.y =
    y0 + (x - x0) * xform->eM12 + (y - y0) * xform->eM22 + xform->eDy + 0.5f;

What happens if you remove the +0.5f from them? I'm guessing they're
there to influence the rounding during conversion from a floating
point calculation into an integer?

(Also I finally now understand a lot of the problems you had
implementing this as it's quite a different approach than the other
terminals and the matrices we produce are not a good fit.)
-- 
Alan Third