From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Juan =?utf-8?Q?Jos=C3=A9_Garc=C3=ADa-Ripoll?= Newsgroups: gmane.emacs.devel Subject: Re: GDI+ take 3 Date: Tue, 21 Apr 2020 09:35:05 +0200 Organization: Institute of Fundamental Physics, CSIC Message-ID: <865zdt70ly.fsf@csic.es> References: <83d088fwgt.fsf@gnu.org> <835ze0fqk2.fsf@gnu.org> <83sgh3eogs.fsf@gnu.org> <838sitazal.fsf@gnu.org> <86imhxufx9.fsf@csic.es> <83y2qsap7r.fsf@gnu.org> <20200418201943.GA57763@breton.holly.idiocy.org> <868sirzsi3.fsf@csic.es> <867dybxmqh.fsf@csic.es> <837dyai8gh.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="32715"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (windows-nt) To: emacs-devel@gnu.org Cancel-Lock: sha1:5Q3tGefNoVNyHBGi4WlQIs/FEtQ= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 21 09:36:14 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jQnS1-0008OG-Bv for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Apr 2020 09:36:13 +0200 Original-Received: from localhost ([::1]:52472 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQnS0-0005dt-EK for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Apr 2020 03:36:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39412) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQnR5-0004qZ-6k for emacs-devel@gnu.org; Tue, 21 Apr 2020 03:35:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQnR4-0005Es-MD for emacs-devel@gnu.org; Tue, 21 Apr 2020 03:35:14 -0400 Original-Received: from ciao.gmane.io ([159.69.161.202]:46978) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jQnR4-0005E2-9O for emacs-devel@gnu.org; Tue, 21 Apr 2020 03:35:14 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jQnR1-0007DB-Vs for emacs-devel@gnu.org; Tue, 21 Apr 2020 09:35:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=159.69.161.202; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/21 02:25:51 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Received-From: 159.69.161.202 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:247456 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Eli Zaretskii writes: >> From: Juan José García-Ripoll >> >> Date: Sun, 19 Apr 2020 22:08:06 +0200 >> >> The image that was supplied by Alan has a nominal delay time of 0.03 >> seconds between frames. Emacs 26.3 takes about 0.14 seconds on average >> to load each frame of the gif file, using giflib. Emacs 28 as I built it >> from git source right now, takes 0.3 seconds with giflib and a time that >> grows from 0.01 up to 0.16 seconds (probably because frames have to be >> read sequentially, there is no index). > > Can you show the Lisp you used to time this? I'd like to see what > times I get here. It is attached. Note that it is an ugly hack. I am rewriting image-animate-timeout because I have to get access to the internal variables. > Also, do you have any suggestions how to fix this? Perhaps we should first > create the images and cache them, and only then start the animation? Some > other ideas? That is one option. I am not sure about the logic on caching, and whether it warrants that all frames would be kept in memory. Other than that, one might have to reconsider the current mechanism how images are built. In all platforms, when using giflib, images cleared various times and built using PUT_PIXEL. I think this is behind the slowdown compared to GDI+. To make an informed decision, it would be appropriate to know what happens on other platforms. In OSX it seems that loading of gifs is fast enough that, like GDI+, no fix would be required. What about Xwindows / Cairo? Does it vary much? I do not have machines to gather this information Cheers -- Juan José García Ripoll http://juanjose.garciaripoll.com http://quinfog.hbar.es --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=image-test.el Content-Transfer-Encoding: quoted-printable ;;(setq w32-use-native-image-API t)=0D (require 'image)=0D (defun image-animate-timeout (image n count time-elapsed limit target-time)= =0D "Display animation frame N of IMAGE.=0D N=3D0 refers to the initial animation frame.=0D COUNT is the total number of frames in the animation.=0D TIME-ELAPSED is the total time that has elapsed since=0D `image-animate-start' was called.=0D LIMIT determines when to stop. If t, loop forever. If nil, stop=0D after displaying the last animation frame. Otherwise, stop=0D after LIMIT seconds have elapsed.=0D The minimum delay between successive frames is `image-minimum-frame-delay'.= =0D =0D If the image has a non-nil :speed property, it acts as a multiplier=0D for the animation speed. A negative value means to animate in reverse."=0D (when (and (buffer-live-p (plist-get (cdr image) :animate-buffer))=0D ;; Delayed more than two seconds more than expected.=0D (or (time-less-p (time-since target-time) 2)=0D (progn=0D (message "Stopping animation; animation possibly too big= ")=0D nil)))=0D (image-show-frame image n t)=0D (let* ((speed (image-animate-get-speed image))=0D (time (current-time))=0D (animation (image-multi-frame-p image))=0D (time-to-load-image (time-since time))=0D (stated-delay-time (/ (or (cdr animation)=0D image-default-frame-delay)=0D (float (abs speed))))=0D ;; Subtract off the time we took to load the image from the=0D ;; stated delay time.=0D (delay (max (float-time (time-subtract stated-delay-time=0D time-to-load-image))=0D image-minimum-frame-delay))=0D done)=0D (message "Time: %S, time-to-load-image: %S, stated-delay-time: %S, sp= eed: %S"=0D time time-to-load-image stated-delay-time speed)=0D (setq n (if (< speed 0)=0D (1- n)=0D (1+ n)))=0D (if limit=0D (cond ((>=3D n count) (setq n 0))=0D ((< n 0) (setq n (1- count))))=0D (and (or (>=3D n count) (< n 0)) (setq done t)))=0D (setq time-elapsed (+ delay time-elapsed))=0D (if (numberp limit)=0D (setq done (>=3D time-elapsed limit)))=0D (unless done=0D (run-with-timer delay nil #'image-animate-timeout=0D image n count time-elapsed limit=0D (+ (float-time) delay))))))=0D =0D =0D (setq debug-on-error t)=0D (defvar test-image (create-image "image-test-large.gif"))=0D (message "Delay: %S" (image-multi-frame-p test-image))=0D (insert-image test-image)=0D (pop-to-buffer "*Messages*")=0D (image-animate test-image)=0D --=-=-=--