bug#54242: 29.0.50; Cannot see WebP imags in Lucid build

bug#54242: 29.0.50; Cannot see WebP imags in Lucid build

[Jean Louis]

I cannot know if this problem is related to Lucid version as subject may
suggest. I cannot see WebP images, I can see only a square appearing.


In GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.4, Xaw3d scroll bars)
 of 2022-02-18 built on protected.rcdrun.com
Repository revision: 51e51ce2df46fc0c6e17a97e74b00366bb9c09d8
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Parabola GNU/Linux-libre

Configured using:
 'configure --with-x-toolkit=lucid'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XAW3D XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: @im=exwm-xim
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-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
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config
gnus-util text-property-search time-date mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils shell pcomplete comint
ansi-color ring seq gv subr-x byte-opt bytecomp byte-compile cconv
image-mode exif misearch multi-isearch dired-aux cl-loaddefs cl-lib
dired dired-loaddefs iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 77936 8438)
 (symbols 48 7088 3)
 (strings 32 20546 2022)
 (string-bytes 1 640671)
 (vectors 16 13852)
 (vector-slots 8 183802 32844)
 (floats 8 32 54)
 (intervals 56 6026 0)
 (buffers 992 14))

-- 
Thanks,
Jean Louis

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

bug#54242: 29.0.50; Cannot see WebP imags in Lucid build

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jean Louis <bugs@gnu.support> writes:

> I cannot know if this problem is related to Lucid version as subject may
> suggest. I cannot see WebP images, I can see only a square appearing.

What sort of square?  Is it a hollow outlined rectangle with the cursor
color that displays in place of the image?

Also, which WebP image did you use to test?

Thanks.

bug#54242: 29.0.50; Cannot see WebP imags in Lucid build

[Lars Ingebrigtsen]

Jean Louis <bugs@gnu.support> writes:

> I cannot know if this problem is related to Lucid version as subject may
> suggest. I cannot see WebP images, I can see only a square appearing.

Do you have a recipe to reproduce this problem, starting from "emacs -Q"?

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

bug#54242: 29.0.50; Cannot see WebP imags in Lucid build

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2022-03-06 03:45]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > I cannot know if this problem is related to Lucid version as subject may
> > suggest. I cannot see WebP images, I can see only a square appearing.
> 
> Do you have a recipe to reproduce this problem, starting from "emacs -Q"?

It applies to animated webp images.

Normal webp images I can see in Emacs, but animated webp images I
cannot. I see only rectangle, though vwebp can show them animated.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

bug#54242: 29.0.50; Cannot see WebP imags in Lucid build

[Lars Ingebrigtsen]

Jean Louis <bugs@gnu.support> writes:

> It applies to animated webp images.

Here's an example animated webp image, and indeed, Emacs fails at
displaying it:

https://mathiasbynens.be/demo/animated-webp-supported.webp

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

bug#54242: Emacs can't display animated webp images

[Lars Ingebrigtsen]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Here's an example animated webp image, and indeed, Emacs fails at
> displaying it:
>
> https://mathiasbynens.be/demo/animated-webp-supported.webp

I've started poking at this just to see what's necessary.  As a first
attempt, I thought we could at least display the first frame in the
animate image, so I did the following according to the er documentation
from Google.


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

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


And indeed, I end up with something that looks like a mangled version of
the nyan cat in the test URL above -- but with wrong width and height or
something?  

The first image in the animation is very simple, though -- frame
width/height is the same as the canvas width height...  so I must be
doing something obviously wrong:

Data: 400 400 400 400 0 0

Anybody spot the obvious error?

There's also the "animation" functions from libwebp, but they are even
less clear as to how they're supposed to be used.

Amusingly, imagemagick also renders the animated webp image wrong, but
in a different way.

diff --git a/configure.ac b/configure.ac
index cda2a04be9..fc409ce8f1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2692,6 +2692,7 @@ AC_DEFUN
 
       EMACS_CHECK_MODULES([WEBP], [$WEBP_MODULE])
       AC_SUBST(WEBP_CFLAGS)
+      WEBP_LIBS="-lwebp -lwebpdemux"
       AC_SUBST(WEBP_LIBS)
    fi
    if test $HAVE_WEBP = yes; then
diff --git a/src/image.c b/src/image.c
index 519eafb904..f175be8923 100644
--- a/src/image.c
+++ b/src/image.c
@@ -9053,6 +9053,7 @@ gif_load (struct frame *f, struct image *img)
  ***********************************************************************/
 
 #include "webp/decode.h"
+#include "webp/demux.h"
 
 /* Indices of image specification fields in webp_format, below.  */
 
@@ -9224,19 +9225,61 @@ webp_load (struct frame *f, struct image *img)
       goto webp_error1;
     }
 
-  /* Decode WebP data.  */
-  uint8_t *decoded;
-  int width, height;
-  if (features.has_alpha)
-    /* Linear [r0, g0, b0, a0, r1, g1, b1, a1, ...] order.  */
-    decoded = WebPDecodeRGBA (contents, size, &width, &height);
+  uint8_t *decoded = NULL;
+  int width, height, x_offset = 0, y_offset = 0, fwidth, fheight;
+
+  if (features.has_animation)
+    {
+      /* Animated image.  */
+      WebPData webp_data;
+      webp_data.bytes = WebPMalloc (size);
+      webp_data.size = size;
+      memcpy ((void*) webp_data.bytes, contents, size);
+      
+      WebPDemuxer* demux = WebPDemux(&webp_data);
+      width = WebPDemuxGetI(demux, WEBP_FF_CANVAS_WIDTH);
+      height = WebPDemuxGetI(demux, WEBP_FF_CANVAS_HEIGHT);
+
+      WebPIterator iter;
+      if (WebPDemuxGetFrame (demux, 1, &iter)) {
+	do {
+	  fprintf(stderr, "Complete is %d %d\n", iter.complete, iter.has_alpha);
+	  /* Decode WebP data.  */
+	  if (iter.has_alpha)
+	    /* Linear [r0, g0, b0, a0, r1, g1, b1, a1, ...] order.  */
+	    decoded = WebPDecodeRGBA (iter.fragment.bytes, iter.fragment.size,
+				      &fwidth, &fheight);
+	  else
+	    /* Linear [r0, g0, b0, r1, g1, b1, ...] order.  */
+	    decoded = WebPDecodeRGB (iter.fragment.bytes, iter.fragment.size,
+				     &fwidth, &fheight);
+	  x_offset = iter.x_offset;
+	  y_offset = iter.y_offset;
+	  fwidth = iter.width;
+	  fheight = iter.height;
+	  break;
+	} while (WebPDemuxNextFrame (&iter));
+	WebPDemuxReleaseIterator (&iter);
+      }
+      WebPDataClear (&webp_data);
+      WebPDemuxDelete (demux);
+    }
   else
-    /* Linear [r0, g0, b0, r1, g1, b1, ...] order.  */
-    decoded = WebPDecodeRGB (contents, size, &width, &height);
+    {
+      /* Non-animated image.  */
+      if (features.has_alpha)
+	/* Linear [r0, g0, b0, a0, r1, g1, b1, a1, ...] order.  */
+	decoded = WebPDecodeRGBA (contents, size, &width, &height);
+      else
+	/* Linear [r0, g0, b0, r1, g1, b1, ...] order.  */
+	decoded = WebPDecodeRGB (contents, size, &width, &height);
+      fwidth = width;
+      fheight = height;
+    }
 
   if (!decoded)
     {
-      image_error ("Error when interpreting WebP image data");
+      image_error ("Error when decoding WebP image data");
       goto webp_error1;
     }
 
@@ -9266,9 +9309,11 @@ webp_load (struct frame *f, struct image *img)
   init_color_table ();
 
   uint8_t *p = decoded;
-  for (int y = 0; y < height; ++y)
+  fprintf(stderr, "Data: %d %d %d %d %d %d\n", width, height, fwidth, fheight,
+	  x_offset, y_offset);
+  for (int y = y_offset; y < fheight; ++y)
     {
-      for (int x = 0; x < width; ++x)
+      for (int x = x_offset; x < fwidth; ++x)
 	{
 	  int r = *p++ << 8;
 	  int g = *p++ << 8;

bug#54242: Emacs can't display animated webp images

[Lars Ingebrigtsen]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Anybody spot the obvious error?

It always helps to post complaints about stuff like this, because then
you immediately spot the problem.  (It was alpha confusion.)


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

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


So now all that's needed is to implement the action animation bits (a la
how the gif code does it, I guess).

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

bug#54242: Emacs can't display animated webp images

[Lars Ingebrigtsen]

I've now got basic webp animation working, and it seems to have
acceptable speed (it looks like I'll be able to reuse the general image
cache to avoid quadratic behaviour as we have in gif_load).

I now just have to program up the more subtle bits of how animated
frames are to be combined, and we should be OK.

I spent much of the time trying to figure out why my code was
segfaulting...  but it turns out that the webp_load function we have
today on the trunk is also segfaulting with the images I'm testing with.
:-/  So that'll also be fixed.

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

bug#54242: Emacs can't display animated webp images

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I now just have to program up the more subtle bits of how animated
> frames are to be combined, and we should be OK.

I had to reimplement it a different way and with a different cache, and
now it works and the performance seems OK.

I've tried to get the Windows DLL stuff right for the Windows, but I
don't have a Windows VM to test with at the moment.  Eli, can you check
whether the trunk compiles, and if not, do the necessary adjustments if
I've forgotten some of the DEF_DLL_FN things for the new functions?

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

bug#54242: Emacs can't display animated webp images

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 10 Apr 2022 13:12:39 +0200
> 
> I've tried to get the Windows DLL stuff right for the Windows, but I
> don't have a Windows VM to test with at the moment.  Eli, can you check
> whether the trunk compiles, and if not, do the necessary adjustments if
> I've forgotten some of the DEF_DLL_FN things for the new functions?

It needed a few fixes, since a second DLL is involved, and some of the
functions were defined inline in the headers to call internal variants.

Now it builds and works on MS-Windows , but can you point me to the
animated images you used to test, so I could see that it works
correctly on Windows?

bug#54242: Emacs can't display animated webp images

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It needed a few fixes, since a second DLL is involved, and some of the
> functions were defined inline in the headers to call internal variants.

Ah, right, forgot about the second DLL when I was typing in the Windows
stuff.  Thanks for fixing.

> Now it builds and works on MS-Windows , but can you point me to the
> animated images you used to test, so I could see that it works
> correctly on Windows?

I've been using a HTML file containing:

<img src="https://mathiasbynens.be/demo/animated-webp-supported.webp">

And visiting it with eww, because that's the easiest way to ensure
triggering the animation machinery.

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

bug#54242: Emacs can't display animated webp images

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 54242@debbugs.gnu.org
> Date: Sun, 10 Apr 2022 15:54:22 +0200
> 
> > Now it builds and works on MS-Windows , but can you point me to the
> > animated images you used to test, so I could see that it works
> > correctly on Windows?
> 
> I've been using a HTML file containing:
> 
> <img src="https://mathiasbynens.be/demo/animated-webp-supported.webp">
> 
> And visiting it with eww, because that's the easiest way to ensure
> triggering the animation machinery.

It seems to work, but flickers like dickens.  Is that expected?

bug#54242: Emacs can't display animated webp images

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It seems to work, but flickers like dickens.  Is that expected?

It doesn't flicker here...  do other animated images (like GIFs) flicker
for you?  Under X, there's double-buffering, if I recall correctly, but
I have no idea what the state is on Windows.

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

bug#54242: Emacs can't display animated webp images

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 54242@debbugs.gnu.org
> Date: Sun, 10 Apr 2022 15:58:33 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It seems to work, but flickers like dickens.  Is that expected?
> 
> It doesn't flicker here...  do other animated images (like GIFs) flicker
> for you?  Under X, there's double-buffering, if I recall correctly, but
> I have no idea what the state is on Windows.

There's no double-buffering on Windows.  Does it flicker if you
disable double-buffering?

Which animated GIF files do you want me to try?  (AFAIR, they didn't
flicker when I tried, but that was a long time ago, and I may have
forgotten.)

bug#54242: Emacs can't display animated webp images

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> There's no double-buffering on Windows.  Does it flicker if you
> disable double-buffering?

Let's see...  I tried:

(modify-all-frames-parameters '((inhibit-double-buffering . t)))

but I still didn't get any flickering.

> Which animated GIF files do you want me to try?  (AFAIR, they didn't
> flicker when I tried, but that was a long time ago, and I may have
> forgotten.)

For instance:

<img src="https://c.tenor.com/z0ZSdKfHpHoAAAAC/coronavirus-corona.gif">


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

bug#54242: Emacs can't display animated webp images

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 54242@debbugs.gnu.org
> Date: Sun, 10 Apr 2022 16:24:29 +0200
> 
> > Which animated GIF files do you want me to try?  (AFAIR, they didn't
> > flicker when I tried, but that was a long time ago, and I may have
> > forgotten.)
> 
> For instance:
> 
> <img src="https://c.tenor.com/z0ZSdKfHpHoAAAAC/coronavirus-corona.gif">

This one doesn't flicker at all.

bug#54242: Emacs can't display animated webp images

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> This one doesn't flicker at all.

Does Windows use the native image support for GIFs, perhaps?

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

bug#54242: Emacs can't display animated webp images

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 54242@debbugs.gnu.org
> Date: Sun, 10 Apr 2022 16:32:56 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This one doesn't flicker at all.
> 
> Does Windows use the native image support for GIFs, perhaps?

It does, but I tested both with native APIs and with libgif, and none
of them flickers.

bug#54242: Emacs can't display animated webp images

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It does, but I tested both with native APIs and with libgif, and none
> of them flickers.

Then I'm afraid I have no further ideas.  Both webp_load and gif_load
return data on the same format to Emacs, so by the time the images reach
the redisplay engine, there shouldn't be any differences.

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