From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Evgeny Zajcev Newsgroups: gmane.emacs.devel Subject: Re: Lazy image converters Date: Sun, 16 Feb 2020 20:45:41 +0300 Message-ID: References: <87lfp2wuj0.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008b706f059eb502b5" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="82824"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Feb 16 18:46:43 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 1j3O0A-000LRs-Sv for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Feb 2020 18:46:42 +0100 Original-Received: from localhost ([::1]:34706 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3O0A-0000Vj-05 for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Feb 2020 12:46:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50917) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3NzQ-0008T2-RJ for emacs-devel@gnu.org; Sun, 16 Feb 2020 12:45:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3NzP-0007Ik-1U for emacs-devel@gnu.org; Sun, 16 Feb 2020 12:45:56 -0500 Original-Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]:36337) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j3NzO-0007BA-Jg for emacs-devel@gnu.org; Sun, 16 Feb 2020 12:45:54 -0500 Original-Received: by mail-lj1-x232.google.com with SMTP id r19so16165337ljg.3 for ; Sun, 16 Feb 2020 09:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lmh8fqoHfVUEwhj16L3168X22cu+SLT2xSnWsM+UjMM=; b=AT0zcTtfrYp4eA8rKR2aBAiWcMwBGoKuIIXWvVx+HbOzobbk+GJkwCtCOQAOdth0Td bryGu4bdZFiSmo+s8JyoYETlMIw23cbtk3hYxSUVhB5IlA+EDI79828JCYwon46bi7dZ 5WQOfdYDxiDUl5G40DI1fkx5UJqn3CgTSqU1vFsWYDcbS64j/WGp6nSd1WVfs2zCmbDl urIEYmB+S1wseKchd0PbH/RqZTs1T5BO/9wvbS27MC953zyy7+HTToEejDo6GR2C49um ZANRHttxNQoJ0lS4rP/xLg1/5H7z+SM8efML9mspOid0ywK+f3ev2dxswo2vuIPv2UJx eubQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lmh8fqoHfVUEwhj16L3168X22cu+SLT2xSnWsM+UjMM=; b=fGwunP3dafVGmk9beVE3Y7cAxKRGaX7p1WH/k7WZdPLAu2X3CfaDO+GPl0O5wwAxNA 2QEYn8JzgaX3yiJ0BRrwsZVy7BvDT/xI9/gL+kuI8farjx5Zp/hY/5n4bs3tmRVXgUDS RDB1JgrJ8E1K1QRUspHP9MQOhIO6+PIDOMESBFU6+V0b99rKpwf7S+1NCetgSELMD+pa hgLpKdxvcGNK0wb+b0Ng9osWIHuViWQYQVxKXbHJNr+PAQlAmYTtDYcVCv3QYS7jX1VW ZJl2epzSTVPiSX8A0WMxPKnMFhQCxEhx6i+k7hxL5MqxI7G01QOfxEhiR54XYzROMZmt vdWg== X-Gm-Message-State: APjAAAWfYS0Qvdr2bH2jAaZaogX8hBz/rT5XNOGW6mzbvgQF6N8MPyUz Aq9iJqpJC/JerxXauvsnZgyFteCqyeZJxdoSCqK2IA== X-Google-Smtp-Source: APXvYqwAldJzxlf0PSDQeLO0EXGCtXrvRLZALo6QrPT3N3F7WJYOUVr+LXAbgwjOpCTGdBzYyT2+3rvGPOmGWqZzEto= X-Received: by 2002:a2e:9dc3:: with SMTP id x3mr7871972ljj.257.1581875152514; Sun, 16 Feb 2020 09:45:52 -0800 (PST) In-Reply-To: <87lfp2wuj0.fsf@gnus.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::232 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:244971 Archived-At: --0000000000008b706f059eb502b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D0=B2=D1=81, 16 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3. =D0=B2 16:07, Lars = Ingebrigtsen : > Evgeny Zajcev writes: > > > What if we have a lazy image, so its FILE-OR-DATA is calculated at > > redisplay time. 'image-convert' could utilize this. One of the > > approaches to lazy images is to allow FILE-OR-DATA to be a function > > returning actual file or data. Redisplay could call this func and > > substitute the value of FILE-OR-DATA in image spec with the results, > > kind of caching the results. > > Hm... It does sound nice, but I worry about calling this complicated > (and slow) code from redisplay. > > Converting to supported format is not that slow. It is aproximately two times slower than reading and decoding already done in redisplay. Also such converter functions are not that complicated to avoid calling them in redisplay But benefits are significant. We will have unified interface to images. You won't distinguish normal images from converted. Can insert any number of images of any kind without locks And in my experience, most of the time when you put images in a buffer, > you're going to display them, so it's not clear that this would often be > a win, UX wise. > > No quite. Sometimes you just need to see some part of the buffer to decide what you going to do. Consider cycling through list of the directories, searching for some image. You select some dir and help buffer pops up showing images in this dir, but actually few of them only visible, but this is enough for the user to decide that this directory is not suitable and he need to go to the next one. I can see it being so when preparing huge directory-like buffers (with > images; I do that for my music playing interface) -- then the user will > normally only display a small subsection of the images, and then > delaying the processing of the images is a win. > > And the same is the case for web pages, I guess, but there the download > time dwarfs anything Emacs does, so it wouldn't make much difference > there, I think? > > Thin strategy to create and append buffer contents as user scrolls the buffer, complicates things a lot. You need many things to think about, such as: 1) If window with buffer is visible, you insert only content that is visibl= e 2) If buffer is invisible you generate nothing and install some hook to take action, when buffers get visibility to add content 3) You need to control scrolling to take care of what is visible in buffer's window and add/remove invisible parts of the buffer 4) If something changes in the buffer (image updated, or new image is added) you also can't just insert it, you need to check is that part of the buffer is actually visible and delay the update/addon action More logic might be required and it is very very similar to what redisplay is actually does Fourth is especially significant for online image manipulations, when images are downloaded from the network and might be updated at any time by the server. So... I'm not convinced of the utility here, especially compared to the > potential problems arising from running complicated Lisp code from > redisplay. > > --=20 > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no > --=20 lg --0000000000008b706f059eb502b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=D0=B2=D1=81, 16 =D1=84=D0=B5=D0=B2=D1=80= . 2020 =D0=B3. =D0=B2 16:07, Lars Ingebrigtsen <larsi@gnus.org>:
Evgeny Zajcev <lg.zevlg@gmail.com> writ= es:

> What if we have a lazy image, so its FILE-OR-DATA is calculated at
> redisplay time.=C2=A0 'image-convert' could utilize this.=C2= =A0 One of the
> approaches to lazy images is to allow FILE-OR-DATA to be a function > returning actual file or data.=C2=A0 Redisplay could call this func an= d
> substitute the value of FILE-OR-DATA in image spec with the results, > kind of caching the results.

Hm...=C2=A0 It does sound nice, but I worry about calling this complicated<= br> (and slow) code from redisplay.


Converting to supported format is not = that slow. It is aproximately two times slower than reading and decoding al= ready done in redisplay.=C2=A0 Also such converter functions are not that c= omplicated to avoid calling them in redisplay

But = benefits are significant.=C2=A0 We will have unified interface to images.= =C2=A0 You won't distinguish normal images from converted.=C2=A0 Can in= sert any number of images of any kind without locks

And in my experience, most of the time when you put images in a buffer,
you're going to display them, so it's not clear that this would oft= en be
a win, UX wise.


No quite.=C2=A0 Sometimes you just nee= d to see some part of the buffer to decide what you going to do.=C2=A0 Cons= ider cycling through list of the directories, searching for some image.=C2= =A0 You select some dir and help buffer pops up showing images in this dir,= but actually few of them only visible, but this is enough for the user to = decide that this directory is not suitable and he need to go to the next on= e.

I can see it being so when preparing huge directory-like buffers (with
images; I do that for my music playing interface) -- then the user will
normally only display a small subsection of the images, and then
delaying the processing of the images is a win.

And the same is the case for web pages, I guess, but there the download
time dwarfs anything Emacs does, so it wouldn't make much difference there, I think?


Thin strategy to create and append buf= fer contents as user scrolls the buffer, complicates things a lot.=C2=A0 Yo= u need many things to think about, such as:
1) If window with buf= fer is visible, you insert only content that is visible
2) If buf= fer is invisible you generate nothing and install some hook to take action,= when buffers get visibility to add content
3) You need to contro= l scrolling to take care of what is visible in buffer's window and add/= remove invisible parts of the buffer
4) If something changes in t= he buffer (image updated, or new image is added) you also can't just in= sert it, you need to check is that part of the buffer is actually visible a= nd delay the update/addon action

More logic might = be required and it is very very similar to what redisplay is actually does<= /div>

Fourth is especially significant for online image = manipulations, when images are downloaded from the network and might be upd= ated at any time by the server.

So...=C2=A0 I'm not convinced of the utility here, especially compared = to the
potential problems arising from running complicated Lisp code from
redisplay.
=C2=A0
--
(domestic pets only, the antidote for overdose, milk.)
=C2=A0 =C2=A0bloggy blog: http://lars.ingebrigtsen.no


--
lg
--0000000000008b706f059eb502b5--