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

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

[ynyaaa]

The form below displays same images with different rotation, different
format. The first line shows the image in XPM format. The second line
shows the same image converted into PNG format. The image looks like:
  [transparent][    red    ]
  [   green   ][    blue   ]

The third image in the first line is the XPM image rotated in 180
degrees. It should looks like:
  [    blue   ][   green   ]
  [    red    ][transparent]
but displayed as:
  [transparent][   green   ]
  [    red    ][   black   ]

The first image in the second line is the PNG image without rotation.
The transparent pixel is displayed as black.

The second to fourth image in the second line are the PNG images rotated
in 90 to 270 degrees. They are invisible as if the entire images are
transparent.

(let ((buf (generate-new-buffer "tmp"))
      (xpm "/* XPM */
static char * test_xpm[] = {
\"2 2 4 1\",
\".\tc None\",
\"R\tc #FF0000\",
\"G\tc #00FF00\",
\"B\tc #0000FF\",
\".R\",
\"GB\"};
")
      (png "\211PNG\r\n\032\n\0\0\0\rIHDR\0\0\0\002\
\0\0\0\002\004\003\0\0\0\200\230\020\027\0\0\0\017PLTE\
\0\0\0\377\0\0\0\377\0\0\0\377\377\377\377\201\347\260\355\
\0\0\0\001tRNS\0@\346\330f\0\0\0\014IDAT\010\327c`dP\006\0\0*\
\0%\323\224\340\204\0\0\0\0IEND\256B`\202"))
  (switch-to-buffer buf)
  (insert " ")
  (insert-image (create-image xpm 'xpm t :scale 20))
  (insert " ")
  (insert-image (create-image xpm 'xpm t :scale 20 :rotation 90))
  (insert " ")
  (insert-image (create-image xpm 'xpm t :scale 20 :rotation 180))
  (insert " ")
  (insert-image (create-image xpm 'xpm t :scale 20 :rotation 270))
  (insert " \n ")
  (insert-image (create-image png 'png t :scale 20))
  (insert " ")
  (insert-image (create-image png 'png t :scale 20 :rotation 90))
  (insert " ")
  (insert-image (create-image png 'png t :scale 20 :rotation 180))
  (insert " ")
  (insert-image (create-image png 'png t :scale 20 :rotation 270))
  (insert " \n")
  (put-text-property (point-min) (point-max) 'face '(:background "grey")))



In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
 of 2020-08-22 built on CIRROCUMULUS
Repository revision: 86d8d76aa36037184db0b2897c434cdaab1a9ae8
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
System Description: Microsoft Windows 10 Pro (v10.0.1909.18363.1379)

Recent messages:

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(gnutls network-stream nsm mailalias smtpmail auth-source eieio
eieio-core cl-macs eieio-loaddefs json map rect wid-edit descr-text
mule-util cl-extra help-fns radix-tree misearch multi-isearch pp shadow
sort emacsbug sendmail mail-extr message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq
byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader cl-seq image-mode exif
term/bobcat help-mode easymenu cl-loaddefs cl-lib japan-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 80508 31642)
 (symbols 48 21222 6)
 (strings 32 81414 6409)
 (string-bytes 1 1948745)
 (vectors 16 17956)
 (vector-slots 8 1025460 97518)
 (floats 8 49 310)
 (intervals 56 2064 179)
 (buffers 1000 27))

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

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 164 bytes --]

ynyaaa@gmail.com writes:

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

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


[-- Attachment #2: Type: image/png, Size: 388 bytes --]

[-- Attachment #3: Type: text/plain, Size: 76 bytes --]


This is on Debian bullseye.

In Emacs 27, I get something very different:


[-- Attachment #4: Type: image/png, Size: 12968 bytes --]

[-- Attachment #5: Type: text/plain, Size: 313 bytes --]


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

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:
> ynyaaa@gmail.com 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

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

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

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

[Eli Zaretskii]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

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

> Date: Wed, 17 Feb 2021 19:26:38 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: larsi@gnus.org, ynyaaa@gmail.com, 46556@debbugs.gnu.org
> 
> > 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.


[-- Attachment #2: squares.PNG --]
[-- Type: image/png, Size: 24847 bytes --]

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

[Eli Zaretskii]

[-- Attachment #1: Type: text/plain, Size: 221 bytes --]

> Date: Wed, 17 Feb 2021 19:26:38 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: larsi@gnus.org, ynyaaa@gmail.com, 46556@debbugs.gnu.org
> 
> Can either you or the OP provide a screenshot?

For completeness, attached.


[-- Attachment #2: transparent_squares.PNG --]
[-- Type: image/png, Size: 23036 bytes --]

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

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 <alan@idiocy.org>
> 
> 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.

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 <alan@idiocy.org>
> > 
> > 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