From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alan Third Newsgroups: gmane.emacs.devel Subject: Re: GDI+ take 3 Date: Sat, 25 Apr 2020 17:51:45 +0100 Message-ID: <20200425165145.GB82687@breton.holly.idiocy.org> References: <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> <865zdt70ly.fsf@csic.es> <20200421181734.GA76806@breton.holly.idiocy.org> <83eesgg01b.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="103106"; mail-complaints-to="usenet@ciao.gmane.io" Cc: juanjose.garciaripoll@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 25 18:54:45 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 1jSO4h-000Qgt-QS for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Apr 2020 18:54:43 +0200 Original-Received: from localhost ([::1]:40918 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSO4g-0006Dk-RK for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Apr 2020 12:54:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36028) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSO3z-0005W1-U7 for emacs-devel@gnu.org; Sat, 25 Apr 2020 12:54:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSO3z-000502-HG for emacs-devel@gnu.org; Sat, 25 Apr 2020 12:53:59 -0400 Original-Received: from ip6-2001-08b0-03f8-8129-8cd2-51a8-eef6-6d95.holly.idiocy.org ([2001:8b0:3f8:8129:8cd2:51a8:eef6:6d95]:53460 helo=breton.holly.idiocy.org) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSO3q-0001bb-2U; Sat, 25 Apr 2020 12:53:50 -0400 Original-Received: by breton.holly.idiocy.org (Postfix, from userid 501) id 1FC9220224BB2D; Sat, 25 Apr 2020 17:51:45 +0100 (BST) Mail-Followup-To: Alan Third , Eli Zaretskii , juanjose.garciaripoll@gmail.com, emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: <83eesgg01b.fsf@gnu.org> Received-SPF: none client-ip=2001:8b0:3f8:8129:8cd2:51a8:eef6:6d95; envelope-from=alan@breton.holly.idiocy.org; helo=breton.holly.idiocy.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/25 12:51:46 X-ACL-Warn: Detected OS = ??? X-Received-From: 2001:8b0:3f8:8129:8cd2:51a8:eef6:6d95 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:247800 Archived-At: On Tue, Apr 21, 2020 at 09:34:56PM +0300, Eli Zaretskii wrote: > > Date: Tue, 21 Apr 2020 19:17:34 +0100 > > From: Alan Third > > Cc: emacs-devel@gnu.org > > > > I agree with you, though, that fixing this particular performance > > problem would require us to rethink how we load and cache images. > > I don't think our image caching mechanism was designed to show > animations. It was designed to show a small number of static images > within mostly-textual content. I’ve been thinking a little about if it’s possible to move image loading into modules to be loaded at runtime, and one of the ideas I had to support that may be helpful here. I don’t know too much about Emacs Lisp’s internals, so feel free to shoot this idea down. I believe we could add a new method of defining images which would be, in effect, a pointer to a decoded image. Perhaps a system dependent format, like pixmap on X, or an NSImage object on macOS, but it could easily be some system independent format we devise ourselves. We would have to provide a function (or perhaps modules could provide it) where we pass in a filename, or data, and get back this pointer. The function could also take a range of frame numbers, and return a list of image pointers all decoded at once. When displaying the image instead of passing a filename or data to create-image, we pass in the image pointer, and everything should work more or less the same from there. We would have to rewrite how animations are displayed to update the image from a list of image pointers instead of incrementing the frame count. The image pointer would, presumably, be subject to garbage collection, so we may have to be able to clear any related images from the image cache when it’s garbage collected. I don’t know how practical this is. -- Alan Third