From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Anand Tamariya Newsgroups: gmane.emacs.devel Subject: Re: SVG hack for display engine Date: Fri, 19 Nov 2021 07:02:20 +0530 Message-ID: References: <83zgq41cra.fsf@gnu.org> <83k0h818zw.fsf@gnu.org> <83mtm2zyf6.fsf@gnu.org> <83pmqxyj3j.fsf@gnu.org> <83czmxyaio.fsf@gnu.org> <837dd5y0qg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000be755805d11a3f13" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28513"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alexander Adolf , Emacs Devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 19 02:34:40 2021 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 1mnsnX-0007Hl-Un for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 02:34:40 +0100 Original-Received: from localhost ([::1]:42946 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mnsnW-0007HE-Ao for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Nov 2021 20:34:38 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53172) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnslY-0006EM-V1 for emacs-devel@gnu.org; Thu, 18 Nov 2021 20:32:36 -0500 Original-Received: from [2607:f8b0:4864:20::131] (port=40515 helo=mail-il1-x131.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mnslW-0002FF-Vo; Thu, 18 Nov 2021 20:32:36 -0500 Original-Received: by mail-il1-x131.google.com with SMTP id k1so8618475ilo.7; Thu, 18 Nov 2021 17:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9KGPhvaUtDXSj0HaMnvNTAQfyi/EuC3Q+kOCGcr9W/Y=; b=ZNRsPmwMX0ViBIs1eT7xjowQV1dgSzneA+vgZJjAp7gvSCWjMhPy/+2S84r/pO7j3h InFYsJCWZzxRNu91JjAqtaAN9os+oSi9YDCnnPlqeZ6frHHpRrN6GmfnXVhOaEuEROl8 u7pXkcrhLcC+Kz+wN9DwNHWIKVXwg7jUjl5zK65Wxxi8Mu6Rr3qBcPQ8qdAprJ+ajxbv 8rahMoOWgZIttwg9k05zwxtfJw0Ko9pbpgkaZKA7TzCsC35EH7opsl526IkZ3Zublj8N Y7CPXpMm6l8fwhHAeEimGkAe8tjHd5lX59DgzyU3SQYrje9FMjytIo/S9d5OSrjWusn0 Q/DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9KGPhvaUtDXSj0HaMnvNTAQfyi/EuC3Q+kOCGcr9W/Y=; b=HUjLxOFuCfAvqhh0WjCxAvLaGVoZXRis2Yaj07U5s5dx21SwxinqUiX+Yjuj5Xa4Ei bgS8y7LUhqe2paouTaDixSVG7OMoM4LoebhGAg5sN7kUue78izBSx2H15sQcHPHlSJ94 HyjPuhbtogqEmsaWJqNYdH/lAwtoX8ZSeK6qv0fFf7Zw58E5alVYuu37DCHocbaV0Hc1 kekvtrjrIAPOqEQSd4Xzmxd+yKmw96NuHOs5bzC7dskbW2td0i/UowGdrZRzXGHtmREi xZlyzGpOamYd902dbMm7/LOyqi6vh8Jepv4+50cHgi8Ssu46u7tRjMODTl5NX3+WCDuV 1eOQ== X-Gm-Message-State: AOAM531kIJ2UBE7/qh4lDglFpjaII15NoByVAk/f2lndDqA28iMQ+TSD 27Cx21LJkXdZjiuqrLVPB7/DG4jH7hNVl8Vsk6iTdqwyCGeU21/o X-Google-Smtp-Source: ABdhPJztOVlhL8+h4f5dnVuwNbbjN8+oMASDhaWpHpWfm/gEDvsT+nMhkBtMSHGH3xbL2qXKzlYW/kX5TRV9Jv1xYaM= X-Received: by 2002:a05:6e02:1a2c:: with SMTP id g12mr2369978ile.62.1637285552352; Thu, 18 Nov 2021 17:32:32 -0800 (PST) In-Reply-To: <837dd5y0qg.fsf@gnu.org> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::131 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::131; envelope-from=atamariya@gmail.com; helo=mail-il1-x131.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:279695 Archived-At: --000000000000be755805d11a3f13 Content-Type: text/plain; charset="UTF-8" > So this is only for popping up some additional image on top of the > "normal" Emacs display? Or is the intent to replace some parts of the > "normal" Emacs display, i.e. what we show in the windows of the > regular frames? > > And if this is just for popups, isn't there already some hook ypou > could use for that purpose? If not, what is missing in the existing > hooks? > Two problems in current approach: > I've used (read-event) and (lookup-key) to allow for key translations for > navigation commands. Hopefully with a tighter integration, all of this will > not be required. > - Do you remember I said I am running my own event loop? This means I'm missing out on the key translations that Emacs would normally handle for me. So anything the developer hasn't coded for will remain inaccessible while the mode is in effect. > > - svg-render (svg x y width height) > > svg is a Lisp DOM object as returned by (dom-node). This should use > librsvg to generate a bitmap image of > > svg of size (width x height) and superimpose it at position (x, y) on > the current bitmap being displayed by > > Emacs. > *The current image API takes either a filename or XML string for SVG. This > can be avoided if svg is a > Lisp DOM.* Edit: (dom-node) is defined in > dom.el . > Can you visualize the amount of string serialization, deserialization and SVG parsing happening in a draw or move operation with live feedback? Do you see it performing well for even a moderately sized SVG? Without direct SVG support in the display engine ie. a way for a developer to tell the display engine to use a particular SVG in a DOM form during it's normal display cycle, any such implementation will remain a hack - it works but it could be much better. --000000000000be755805d11a3f13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

So this is only for popping up some additional image on top of the
"normal" Emacs display?=C2=A0 Or is the intent to replace some pa= rts of the
"normal" Emacs display, i.e. what we show in the windows of the regular frames?

And if this is just for popups, isn't there already some hook ypou
could use for that purpose?=C2=A0 If not, what is missing in the existing hooks?
Two problems in current approach:
=C2=A0
I've u= sed (read-event) and (lookup-key) to=20 allow for key translations for navigation commands. Hopefully with a=20 tighter integration, all of this will not be required.
- Do you remember I said I am running my own event = loop? This means I'm missing out on the key translations that Emacs wou= ld normally handle for me. So anything the developer hasn't coded for w= ill remain inaccessible while the mode is in effect.

=C2=A0
> - svg-render (svg x y width height)
> svg is a Lisp DOM object as returned by (dom-node). This should use li= brsvg to generate a bitmap image of
> svg of size (width x height) and superimpose it at position (x, y) on = the current bitmap being displayed by
> Emacs. The current image API takes either a filename or XML string = for SVG. This can be avoided if svg is a
> Lisp DOM. Edit: (dom-node) is defined in dom.el .
Can you visualize the amount of string serializatio= n, deserialization and SVG parsing happening in a draw or move operation wi= th live feedback? Do you see it performing well for even a moderately sized= SVG?

Without direct SVG support in the display en= gine ie. a way for a developer to tell the display engine to use a particul= ar SVG=C2=A0 in a DOM form during it's normal display cycle, any such i= mplementation will remain a hack - it works but it could be much better.
--000000000000be755805d11a3f13--