From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Akira Kyle Newsgroups: gmane.emacs.devel Subject: Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets) Date: Tue, 24 Nov 2020 18:36:38 -0700 Message-ID: <86h7peqkt5.fsf@akirakyle.com> References: <864kmzupp0.fsf@akirakyle.com> <86pn46awrr.fsf@akirakyle.com> <87y2ise7j5.fsf@gnus.org> <86tutfwhr6.fsf@akirakyle.com> <87h7pfb76z.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32897"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.13; emacs 28.0.50 Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 25 02:38:07 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 1khjl1-0008C6-B9 for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Nov 2020 02:38:07 +0100 Original-Received: from localhost ([::1]:36092 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1khjkg-0001IL-Vp for ged-emacs-devel@m.gmane-mx.org; Tue, 24 Nov 2020 20:37:46 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59744) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khjjf-0000nU-RU for emacs-devel@gnu.org; Tue, 24 Nov 2020 20:36:43 -0500 Original-Received: from mail-io1-f45.google.com ([209.85.166.45]:37368) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1khjje-0004Xi-2x for emacs-devel@gnu.org; Tue, 24 Nov 2020 20:36:43 -0500 Original-Received: by mail-io1-f45.google.com with SMTP id d17so548206ion.4 for ; Tue, 24 Nov 2020 17:36:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=tcyFgiH8fVDPWCxPHjpwAeLy4TVEFFTOXr7pbiq3aNI=; b=c2y6L8WicIqHX7+XZZj197JXtCgXxE2Dy2qS4KajVrPWaJPEEj/N3gB9YzEGRcHgW5 6y7yot4VBoOOKu70cabd9W2XWk4wPIMtI3IwOPuiS3Hf003lEVTY3TT86CEnK3S7XcOv hyZwsu3CIq6xOloPn4yKUTzS1W6NN1SPNiV6VUdaPb5KsmNjWK8mPhbjXyW6LR8CkoGM VxyAch7yBLhXyw99zV2cnY+wJiVfcvIgFap4o7aW8Zzt5MroSfFju7QA69bQ0Fm+Auk5 0CXprsXC6W5JqXAIKEe3BqCU7mZc23eDIcnVtc3b+ocqtsrV1xDWcXSAcfM5Sx3vkd6K xleQ== X-Gm-Message-State: AOAM533pKEGjfl+8dFoT9slBtFNQFhV0O4jQ5vr7nrzcKjm4iNy4V5Ub FFLWnjAAx7H12wUntaTV5uuEAorRW1SiXCiC X-Google-Smtp-Source: ABdhPJwAJQMN1SKFMC/jLzwqmwTd/glN29tvJyGBSQQ7zPLhwQ3DPLMcEXJPG4ZoC5645xUxXSeXRA== X-Received: by 2002:a5d:8b87:: with SMTP id p7mr907345iol.96.1606268200585; Tue, 24 Nov 2020 17:36:40 -0800 (PST) Original-Received: from data ([2601:281:8080:45f0:3d98:4a53:b93d:d4ea]) by smtp.gmail.com with ESMTPSA id d5sm295375ilf.33.2020.11.24.17.36.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Nov 2020 17:36:39 -0800 (PST) In-reply-to: <87h7pfb76z.fsf@gnus.org> Received-SPF: pass client-ip=209.85.166.45; envelope-from=aikokyle@gmail.com; helo=mail-io1-f45.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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.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:259758 Archived-At: On Mon, Nov 23, 2020 at 11:27 PM, Lars Ingebrigtsen wrote: >> Thus I feel like the only sane way to mix the two is to allow >> gtk to >> just take over an Emacs window which is always rectangular. No >> need to >> worry about scrolling and all the redisplay optimizations that >> will >> try to interfere with gtk attempting to draw at some point in >> the >> buffer. > > I think this design reduces the use cases for emacs-webkit > considerably > -- if all you can do with it is to let it take over a window > completely, > then that's disappointing. Maybe it's worth expanding on this since I was originally trying to come up a solution that would work more along the lines of what you're asking, but ended up where I am entirely due to technical reasons and perhaps that journey may be informative... Consider that any "rich" display element you might want displayed among others in a buffer needs to have some display property so that redisplay can be aware of it's position relative to other elements in the buffer. Thus there ultimately needs to be some entry in the glyph matrix for this "rich" display element. But the current way redisplay happens, with its various optimizations, you can't expect that every time the element is moved or partially clipped or even removed entirely, that Emacs will ask for your "rich" element to draw itself. So you have two options. One is you make your "rich" element behave pretty much the way images behave and just give Emacs a pixbuf to display. But even then you may need nontrivial redisplay changes due to Emacs not expecting the pixbuf data to change out from underneath itself. The other is you try to do something like what xwidget does and synchronize changes in where redisplay calculates the position of the "rich" element to go with drawing that element yourself (or letting gtk draw it). I see this second option as ultimately being pretty brittle as it needs to force redisplay to draw your glyph every time redisplay changes some properties of its display and pass what those are to your "rich" element and hope that it respects them. If it doesn't or something in this process breaks, your element ends up floating in places it shouldn't be because it keeps drawing itself to the screen there. I think the former approach of expanding the image.c code or creating something modeled after it would be the better approach, likely with less visual bugs. Perhaps cairo could be a key component of this if its okay to have it as a dependency on all platforms. Anyways that was at least the direction my hacking on xwidgets was taking me before I got "sidetracked" by this dynamic module idea.