emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GDI+ take 3


From: Juan José García-Ripoll
Subject: Re: GDI+ take 3
Date: Sat, 18 Apr 2020 19:51:01 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (windows-nt)

Eli Zaretskii <address@hidden> writes:

>> From: Juanma Barranquero <address@hidden>
>> Date: Sat, 18 Apr 2020 17:56:41 +0200
>> Cc: Juan José García-Ripoll <address@hidden>, 
>>      Emacs developers <address@hidden>
>> 
>> That happening / not happening suggest we're accessing some uninitialized
>> memory or some such, I suspect.
>
> That'd be my guess, yes.

Don't think so. If there was corruption, you would see a crash, as it
already happened with TIFF; from what I gather, it simply stops
animating but Emacs keeps working. Couldn't it be just a problem of
latency?

Emacs is doing something rather ugly with animated images: it reloads
them every time a new frame is requested. This means decoding the entire
image; extracting the frame; displaying it; dropping the image. Indeed,
the continuous reloading of images and associated slowdown is one of the
reasons I stopped using equation previews in LaTeX.

My laptop is old, but I have an SSD and never see any problem. When
Emacs runs on a hard disk or the computer is more busy, maybe the timer
cannot catch up with the speed of the animation past some frames and the
image is not updated. Or maybe the timer gets triggered while
decoding.

Probably one does not need to "step" through all the code, but just make
sure w32_load_image gets called, logging those calls and the time they
happen. If they are equally spaced and all succeed, maybe you are right,
but I would guess there is a bottleneck somewhere.

Cheers

-- 
Juan José García Ripoll
http://juanjose.garciaripoll.com
http://quinfog.hbar.es




reply via email to

[Prev in Thread] Current Thread [Next in Thread]