bug#7799: 24.0.50; Animated images display strangely
Chong Yidong
>
> Apparently these are GIF images that have a background images, and the
> rest of the frames are of the "combine" type. Emacs doesn't seem to
> do the right thing in that case, although other animated GIFs look
> fine.
This was fixed a while ago, so I'm closing the bug.
Lars Magne Ingebrigtsen
> This was fixed a while ago, so I'm closing the bug.
It's much better than it used to be, but I'm still seeing some glitches.
With emacs -Q and the latest bzr, eval the following:
(url-retrieve
"http://icanhascheezburger.files.wordpress.com/2011/08/0848b876-a808-4614-ac26-9285d46cc5f7.gif"
(lambda (status)
(goto-char (point-min))
(search-forward "\n\n")
(let ((data (buffer-substring (point) (point-max))))
(pop-to-buffer "*animate*")
(let ((image (create-image data 'gif t)))
(insert-image image)
(image-animate image nil 60)))))
One single frame in the animation looks broken. That seems to be the
case with all my test cases where the image displays buggily. (But most
animated gifs display properly now.) Could it be a off-by-one error of
some kind?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Andy Moreton
> Chong Yidong <c...@stupidchicken.com> writes:
>
>> This was fixed a while ago, so I'm closing the bug.
>
> It's much better than it used to be, but I'm still seeing some glitches.
>
> With emacs -Q and the latest bzr, eval the following:
>
> (url-retrieve
> "http://icanhascheezburger.files.wordpress.com/2011/08/0848b876-a808-4614-ac26-9285d46cc5f7.gif"
> (lambda (status)
> (goto-char (point-min))
> (search-forward "\n\n")
> (let ((data (buffer-substring (point) (point-max))))
> (pop-to-buffer "*animate*")
> (let ((image (create-image data 'gif t)))
> (insert-image image)
> (image-animate image nil 60)))))
>
> One single frame in the animation looks broken. That seems to be the
> case with all my test cases where the image displays buggily. (But most
> animated gifs display properly now.) Could it be a off-by-one error of
> some kind?
I see the same glitchy behaviour in a win32 build of today's trunk,
using the GnuWin32 build of libungif4.dll (v4.1.4.2616).
With http://upload.wikimedia.org/wikipedia/commons/3/37/Clock.gif
(580×580 pixels, 143 frames) I get a segfault.
I'm happy to help debug if somebody more familar with GIFs and image
display can make suggestions as to where to look next:
Program received signal SIGSEGV, Segmentation fault.
0x01295e7c in gif_load (f=0x3703000, img=0x479d480) at image.c:7360
7360 int c = raster[y * image_width + x];
(gdb) info locals
c = 0xfe
subimage = 0xa496f8
raster = 0x724537d8 "\002\002\002\002"
transparency_color_index = 0x2
disposal = 0x0
file = 0x103928d
rc = 0x1
width = 0x244
height = 0x244
x = 0x9c
y = 0xb7
i = 0x4
j = 0x1
ximg = 0x362bdc0
gif_color_map = 0xa47960
pixel_colors = {0x2ffffff, 0x2000000, 0x2d9d9d9, 0x2000000, 0x0 <repeats 252 times>}
gif = 0xa47908
image_height = 0xc9
image_width = 0xd4
memsrc = {
bytes = 0x47a300c "GIF89aD\002D\002\221",
len = 0x27d93,
index = 0x27d93
}
specified_bg = 0x341c81a
specified_file = 0x341c81a
specified_data = 0x47a2e61
bgcolor = 0x0
idx = 0x5
(gdb) bt
#0 0x01295e7c in gif_load (f=0x3703000, img=0x479d480) at image.c:7360
#1 0x0128d5f5 in lookup_image (f=0x3703000, spec=0x47948fe) at image.c:1741
#2 0x0128be90 in Fimage_metadata (spec=0x47948fe, frame=0x341c81a) at image.c:975
#3 0x010368af in Ffuncall (nargs=0x2, args=0x82e780) at eval.c:3012
#4 0x010ddcbc in exec_byte_code (bytestr=0x13ec8f9, vector=0x13ec945, maxdepth=0xc, args_template=0x341c81a, nargs=0x0, args=0x0) at bytecode.c:785
#5 0x0103779c in funcall_lambda (fun=0x13ec8d5, nargs=0x1, arg_vector=0x341c81a) at eval.c:3240
#6 0x01036c48 in Ffuncall (nargs=0x2, args=0x82ea80) at eval.c:3058
#7 0x010ddcbc in exec_byte_code (bytestr=0x13ecb51, vector=0x13ecbc5, maxdepth=0x24, args_template=0x341c81a, nargs=0x0, args=0x0) at bytecode.c:785
#8 0x0103779c in funcall_lambda (fun=0x13ecb15, nargs=0x5, arg_vector=0x341c81a) at eval.c:3240
#9 0x01036c48 in Ffuncall (nargs=0x6, args=0x82eda0) at eval.c:3058
#10 0x010357e3 in Fapply (nargs=0x2, args=0x82eed4) at eval.c:2514
#11 0x010365d5 in Ffuncall (nargs=0x3, args=0x82eed0) at eval.c:2991
#12 0x010ddcbc in exec_byte_code (bytestr=0x13cc269, vector=0x13cc29d, maxdepth=0x10, args_template=0x341c81a, nargs=0x0, args=0x0) at bytecode.c:785
#13 0x010dd278 in Fbyte_code (bytestr=0x13cc269, vector=0x13cc29d, maxdepth=0x10) at bytecode.c:423
#14 0x01034a82 in eval_sub (form=0x13cc25e) at eval.c:2363
#15 0x010327c0 in internal_lisp_condition_case (var=0x341c81a, bodyform=0x13cc25e, handlers=0x1311746) at eval.c:1440
#16 0x010de6dc in exec_byte_code (bytestr=0x13cc169, vector=0x13cc1ed, maxdepth=0x14, args_template=0x341c81a, nargs=0x0, args=0x0) at bytecode.c:981
#17 0x0103779c in funcall_lambda (fun=0x13cc14d, nargs=0x1, arg_vector=0x341c81a) at eval.c:3240
#18 0x01036c48 in Ffuncall (nargs=0x2, args=0x82f5a8) at eval.c:3058
#19 0x01035d89 in call1 (fn=0x342790a, arg1=0x362be85) at eval.c:2778
#20 0x0100e1f8 in timer_check_2 () at keyboard.c:4428
#21 0x0100e272 in timer_check () at keyboard.c:4474
#22 0x0104a966 in wait_reading_process_output (time_limit=0x43, microsecs=0x0, read_kbd=0xffffffff, do_display=0x1, wait_for_cell=0x341c81a, wait_proc=0x0, just_wait_proc=0x0) at process.c:4308
#23 0x010f75da in sit_for (timeout=0x10c, reading=0x1, do_display=0x1) at dispnew.c:5958
#24 0x010091bf in read_char (commandflag=0x1, nmaps=0x2, maps=0x82f9a0, prev_event=0x341c81a, used_mouse_menu=0x82fa68, end_time=0x0) at keyboard.c:2688
#25 0x0101bf4d in read_key_sequence (keybuf=0x82fbec, bufsize=0x1e, prompt=0x341c81a, dont_downcase_last=0x0, can_return_switch_frame=0x1, fix_current_buffer=0x1) at keyboard.c:9283
#26 0x01005bb1 in command_loop_1 () at keyboard.c:1445
#27 0x010328a2 in internal_condition_case (bfun=0x10055b6 <command_loop_1>, handlers=0x342a99a, hfun=0x1004dda <cmd_error>) at eval.c:1493
#28 0x01005212 in command_loop_2 (ignore=0x341c81a) at keyboard.c:1156
#29 0x010322c5 in internal_catch (tag=0x342a1e2, func=0x10051ee <command_loop_2>, arg=0x341c81a) at eval.c:1247
#30 0x010051ce in command_loop () at keyboard.c:1135
#31 0x010047af in recursive_edit_1 () at keyboard.c:756
#32 0x01004aca in Frecursive_edit () at keyboard.c:820
#33 0x010028c5 in main (argc=0x1, argv=0xa44480) at emacs.c:1705
Lisp Backtrace:
"image-metadata" (0x82e784)
"image-animated-p" (0x82ea84)
"image-animate-timeout" (0x82eda4)
"apply" (0x82eed4)
"byte-code" (0x82f120)
"timer-event-handler" (0x82f5ac)
(gdb)
Chong Yidong
> It's much better than it used to be, but I'm still seeing some glitches.
>
> http://icanhascheezburger.files.wordpress.com/2011/08/0848b876-a808-4614-ac26-9285d46cc5f7.gif
>
> One single frame in the animation looks broken. That seems to be the
> case with all my test cases where the image displays buggily. (But
> most animated gifs display properly now.) Could it be a off-by-one
> error of some kind?
Looks like there is off-spec behavior going on---not that the gif89a is
very descriptive in the first place. The "buggy" frame is one which has
disposal method 2, defined in the gif89a spec as
2 - Restore to background color. The area used by the
graphic must be restored to the background color.
And that's exactly what Emacs does, but it looks like web browsers are
rendering the background frame instead, under some circumstances. I'll
take a look when I have the time.