From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets) Date: Sat, 28 Nov 2020 11:19:56 +0200 Message-ID: <83tut9n8hv.fsf@gnu.org> References: <864kmzupp0.fsf@akirakyle.com> <86pn46awrr.fsf@akirakyle.com> <87y2ise7j5.fsf@gnus.org> <86tutfwhr6.fsf@akirakyle.com> <87h7pfb76z.fsf@gnus.org> <86h7peqkt5.fsf@akirakyle.com> <83tutdsc8i.fsf@gnu.org> <86eeker01y.fsf@akirakyle.com> <83wny5naf5.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39061"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, akira@akirakyle.com, emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 28 10:21:11 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 1kiwPm-000A2T-Nf for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 10:21:10 +0100 Original-Received: from localhost ([::1]:45866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiwPl-0007Sk-O8 for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 04:21:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53764) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiwOr-00070T-Mb for emacs-devel@gnu.org; Sat, 28 Nov 2020 04:20:13 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42430) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiwOq-0006gZ-6I; Sat, 28 Nov 2020 04:20:12 -0500 Original-Received: from [176.228.60.248] (port=3383 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kiwOp-0007HL-Fl; Sat, 28 Nov 2020 04:20:11 -0500 In-Reply-To: (message from Arthur Miller on Sat, 28 Nov 2020 09:57:39 +0100) 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:259943 Archived-At: > From: Arthur Miller > Cc: Akira Kyle , larsi@gnus.org, emacs-devel@gnu.org > Date: Sat, 28 Nov 2020 09:57:39 +0100 > > Eli Zaretskii writes: > > > As long as the widget can be told to use a given rectangular portion > > of the screen, we should be fine: the current Emacs display engine is > > perfectly capable of handling display elements that occupy an area of > > certain dimensions. > > How can I tell any drawing routines to use certain rectangular area on > display so it is in harmony with Emacs display engine? On the display engine level, you need to define a new kind of "display element" (see 'enum glyph_type' in dispextern.h) and new kind of method for producing such a display element (see 'enum it_method' in dispextern.h). You will also need to write a BUILD__GLYPH_STRING macro that produces a "glyph string" from one or more display elements of this new type; see BUILD_XWIDGET_GLYPH_STRING in xdisp.c as an example. Glyph strings are the interface between xdisp.c, which parses buffers and strings for display and performs display layout, and xterm.c (see below) which actually draws the resulting display elements. On the Lisp level, you will probably use a special 'display' property whose value specifies the widget with the necessary parameters, like we do with images. > Are there callbacks I can connect too if I would like to update opengl > viewport that I can hook easily into? Where do I look? I am not sure I > understand it from image.c; it was there I was looking. I never looked > into xwidgets though. Can be just me; but if you can point me to right > place to look at I am thankful. The actual drawing is in xterm.c (for X; it's w32term.c for MS-Windows, nsterm.m for NS, and term.c for TTY frames). Each type of display element has a function there, which is called to draw the display element. For example, x_draw_image_glyph_string for drawing images. You will need to write a new function for this new display element, whose parameters are passed from the new it_method method above. Not sure if this is what you meant by "callback to connect to in order to update opengl viewport". (image.c just prepares the data required for drawing an image; its functions are not called when drawing the image, we just use the pixmap produced by image.c and various other parameters, like image dimensions etc.)