From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: trunk r113947: * image.c: Fix animation cache signature memory leak. Date: Mon, 19 Aug 2013 22:55:33 +0200 Message-ID: References: <521244F0.3060508@cs.ucla.edu> <521246C4.3070004@cs.ucla.edu> <52124E37.2080709@cs.ucla.edu> <52127603.5030809@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1376945760 8562 80.91.229.3 (19 Aug 2013 20:56:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Aug 2013 20:56:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 19 22:56:03 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VBWUa-0007cu-SX for ged-emacs-devel@m.gmane.org; Mon, 19 Aug 2013 22:56:01 +0200 Original-Received: from localhost ([::1]:44872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBWUa-0008C3-Hm for ged-emacs-devel@m.gmane.org; Mon, 19 Aug 2013 16:56:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBWUS-0008Bk-Li for emacs-devel@gnu.org; Mon, 19 Aug 2013 16:55:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBWUM-0002Dl-Pj for emacs-devel@gnu.org; Mon, 19 Aug 2013 16:55:52 -0400 Original-Received: from hermes.netfonds.no ([80.91.224.195]:50272) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBWUM-0002DH-G8 for emacs-devel@gnu.org; Mon, 19 Aug 2013 16:55:46 -0400 Original-Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VBWU9-0004Qf-Ru; Mon, 19 Aug 2013 22:55:33 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEUGBQUEAwOKiowfHx8K CgoICAgCAgIxSCPxAAACXklEQVQ4jU2UTXObMBCGV7a5a0vCuV3hO5HM3TGiZxrgHk1m9P9/QvcD pyUz8QyPXu3nCyBiKYhtypeUoNn1yTkDen6N6FOIFAd7P++bANRnCjEmD/siZBMgT4c4+gQOwSQC nAGHaYrpNliQTWJ0HKMWLCRPUMmsQJOqiPeUqBkATKCKUmtlkZ/TlPJw3AWApXb8V2ubiOK0PEGH n1UkFdtwo5SeFUqMioUV+Dq8D9tdjh/AEpb6vbZkni3do8JvkJ+9sved/AB8l/FPIQLnny0xUDvO WAlqkO0Juo5DF98wsVw1hp/e7DbPDYVm3vc1ZI1BBor3AF5uetBNwAvNR2hYnGdFjqSKlhJyr7gM 3wA0HPgAP+h6ZCstkKsizaoIv7RqvDjPwbnuFHYDR1b5Pkrhc55uWepYyVlt5/GqK5IfvcZYyQR4 pnERSX7cFJzp7lVxonnhjmxP0NL4R+860dioYrLKdxqsIy312vZ8tGSh3sCZl0oHla0lIAe5uNeG rpKtgN4AH3R8dqFgk8jRwCM4GaqH2DcXnfcjJQauDe+dduvEwWy0MYjCEUt4d/ElDf4/sC9kTeFu kW0Jj0oUIApN+OfFSV4bg8SKXRSOJ3XqxVEbk4mIFesHvfm3rrSilDXZphwYNIlLnn7Xlv10572C Laepj9zd6+dKqfsSo93YUJd5jXrV+uZLO9cvdtNwHqBhkGSIsMDONiu6C1xGA0tjxuEmqTcrghcb wA4H8PJt4M9FCOnE/0dOS+3Mi+m8V5PTB4U4qm2ObT8cwPHMs+ZBV9i1hSlrARb7yOz5L0utzlFj OfPdAAAAAElFTkSuQmCC X-Now-Playing: Young Marble Giants's _Colossal Youth_: "Cakewalking" X-Hashcash: 1:23:130819:emacs-devel@gnu.org::EurBjj4jN+KHLfd4:0000000000000000000000000000000000000000004CUL X-Hashcash: 1:23:130819:eggert@cs.ucla.edu::mFNvjpWuvGwfObe9:0000000000000000000000000000000000000000000mVvH In-Reply-To: (Lars Magne Ingebrigtsen's message of "Mon, 19 Aug 2013 21:51:30 +0200") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) X-MailScanner-ID: 1VBWU9-0004Qf-Ru MailScanner-NULL-Check: 1377550534.08718@vgKgoCdPv8b2hk3zwdU8DA X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.224.195 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:162894 Archived-At: I think what might really help with the speed is doing more caching and a better liveliness analysis. Or something. First of all, every iteration we re-parse the "super-wand": if (filename) status = MagickReadImage (image_wand, filename); else { filename_hint = imagemagick_filename_hint (img->spec, hint_buffer); MagickSetFilename (image_wand, filename_hint); status = MagickReadImageBlob (image_wand, contents, size); } If we stash that in the cache, too, then my guess would be that we'd see a rather large speed-up. We'd have to have a way to compute an ID for the data, though. I'd suggest just doing a sha256 or something over contents and then perhaps using the same animation cache. It'd need some tweaks, though, because we don't want to cache non-animation images, and we don't know whether they are or not before we've parsed it. :-) The other thing is that imagemagick_compute_animated_image clones the wand before putting it into the cache: cache->wand = CloneMagickWand (composite_wand) This is because imagemagick_load_image later destroys the wand, so we need a copy. This could be avoided, of course, and my guess is that this would also be a nice speed-up, because copying a wand must probably entail copying the entire data. If you could look at this, I think the ImageMagick animation could start approaching the gif animation code speed-wise. At present, it's much slower, especially on large images. This is the code snippet I use to test: (url-retrieve "http://cdn.arwrath.com/1/148330.gif" (lambda (&rest ignore) (search-forward "\n\n") (let ((image (create-image (buffer-substring (point) (point-max)) 'imagemagick t))) (pop-to-buffer "*image*") (erase-buffer) (delete-all-overlays) (put-image image (point) "*") (image-animate image nil 60)))) -- (domestic pets only, the antidote for overdose, milk.) No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html