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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
[hidden email] writes:

> The form below displays same images with different rotation, different
> format.

In Emacs 28, I get the following with the test case:



This is on Debian bullseye.

In Emacs 27, I get something very different:



Which looks all kinds of wrong, so this has changed quite a bit since
Emacs 27.

Would it be possible for you to test with Emacs 28 and see whether the
problem you report (on Windows) is still present there?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

attachment0 (532 bytes) Download Attachment
attachment1 (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Alan Third
On Tue, Feb 16, 2021 at 02:10:43PM +0100, Lars Ingebrigtsen wrote:
> [hidden email] writes:
>
> > The form below displays same images with different rotation, different
> > format.
>
> In Emacs 28, I get the following with the test case:
>


>
> This is on Debian bullseye.
>
> In Emacs 27, I get something very different:
>


>
> Which looks all kinds of wrong, so this has changed quite a bit since
> Emacs 27.

The only difference between the two is that on X with Emacs 28 we use
nearest neighbour filtering on image scale up instead of some
smoothing algorithm.

> 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.

--
Alan Third



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> Date: Tue, 16 Feb 2021 21:24:24 +0000
> From: Alan Third <[hidden email]>
> Cc: [hidden email], [hidden email]
>
> > 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.



Reply | Threaded
Open this post in threaded view
|

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

Alan Third
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 <[hidden email]>
> > Cc: [hidden email], [hidden email]
> >
> > > 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.
--
Alan Third



Reply | Threaded
Open this post in threaded view
|

bug#46554: 27.1; 180 degree rotated image is displayed in slightly different position

Eli Zaretskii
Ouch, I responded to the wrong bug report.  Redirecting.

> Date: Wed, 17 Feb 2021 19:26:38 +0000
> From: Alan Third <[hidden email]>
> Cc: [hidden email], [hidden email], [hidden email]
>
> > 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.
I attach a screenshot, note the 3rd square from the left, where the
red square line seems to be 1 pixel off to the right and down of the
black background.

> 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.

That's the bug I was talking about.  I didn't look closely at
bug#46556, as it talks about transparency, something I have no idea
how it works and indeed whether it's at all supported on MS-Windows.


squares.PNG (33K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Alan Third
> Date: Wed, 17 Feb 2021 19:26:38 +0000
> From: Alan Third <[hidden email]>
> Cc: [hidden email], [hidden email], [hidden email]
>
> Can either you or the OP provide a screenshot?

For completeness, attached.


transparent_squares.PNG (30K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Alan Third
In reply to this post by 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 <[hidden email]>
> > > Cc: [hidden email], [hidden email]
> > >
> > > > 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> Date: Wed, 17 Feb 2021 20:07:27 +0000
> From: Alan Third <[hidden email]>
>
> 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?

Yes.  Removing them produces worse results.

Anyway, as I said earlier, I stepped through the code, and all the
vertices are computed without any roundoff, exactly as expected.
Moreover, the "good" squares, which have no 1-pixel problem, come out
of that code with exactly the same values as the "bad" one, modulo the
shift in X direction.  The members of xform matrix are also exact,
either zero or +/-1.



Reply | Threaded
Open this post in threaded view
|

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

Alan Third
On Wed, Feb 17, 2021 at 10:26:36PM +0200, Eli Zaretskii wrote:

> > Date: Wed, 17 Feb 2021 20:07:27 +0000
> > From: Alan Third <[hidden email]>
> >
> > 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?
>
> Yes.  Removing them produces worse results.
>
> Anyway, as I said earlier, I stepped through the code, and all the
> vertices are computed without any roundoff, exactly as expected.
> Moreover, the "good" squares, which have no 1-pixel problem, come out
> of that code with exactly the same values as the "bad" one, modulo the
> shift in X direction.  The members of xform matrix are also exact,
> either zero or +/-1.

I've found a couple of references to PlgBlt being buggy when rotating
by 180 degrees. Since the values are correct I'm afraid I can't think
of any other explanation.

I can't find any information on this alleged bug. The solution
suggested by one person [1] is to rotate by some slightly different
value, but that is clearly not acceptable here.

I'm sorry I'm not being much help here.

[1] https://www.vbforums.com/showthread.php?863459-PlgBlt-weirdness-or-a-bug&p=5295829&viewfull=1#post5295829

--
Alan Third